RFC 3339 ile ISO 8601 karşılaştırması
(ijmacd.github.io)- Tarih-saat gösterimlerini ele alırken RFC 3339, web ve internet ortamında kullanımı kolay daha dar bir alt kümeye yakındır; ISO 8601-1:2019 ise çok daha geniş bir biçim kümesini kapsar
- Karşılaştırma kapsamı ISO 8601-1:2019 ile sınırlıdır; ISO 8601-2:2019 içindeki mevsimler, kümeler, belirsizlik sınırlamaları ve tarih aritmetiği gibi ek gösterimler tabloya henüz yansıtılmamıştır
- Her iki standart da
2026-06-26,14:08:00Z,2026-06-26T14:08:00Z,+00:00offseti gibi yaygın kullanılan temel tarih-saat biçimlerini kapsar - ISO 8601; yüzyıl, on yıl, ordinal gün, hafta tarihi, kısaltılmış saat, virgüllü ondalık, süre (
P1Y) ve aralık (2026-06-26/P1Y) ifadelerine kadar uzanırken RFC 3339 bunların çoğunu tabloda dışarıda bırakır - Date-Time gösteriminde
Tayıracı, büyük/küçük harf kullanımı ve-00:00offseti gibi farklar, gerçek parser uyumluluğunu belirleyen noktalar haline gelir
Karşılaştırma kapsamı ve varsayımlar
- Biçim tablosu eksiksiz bir liste değildir
- Ele alınan standart ISO 8601-1:2019'dur
- Önceki sürümler ve taslaklar önemli farklar içerir
- ISO 8601-2:2019 ek gösterimler içerir, ancak bu sayfaya henüz yansıtılmamıştır
- Alt yıl grupları, örneğin mevsimler
- Gruplama birimleri
- Kümeler
- Belirsizlik sınırlamaları
- Tarih aritmetiği
- RFC 3339, alt standartlarda
Tyerine başka bir karakter kullanılabileceğini öne sürer, ancak örnek olarak yalnızca boşluk karakteri verir - Her standart amacına uygun biçimleri tanımlar; bunun dışındaki biçimler önerilmez
Tarih gösteriminde ISO 8601 daha geniştir
- Hem RFC 3339 hem de ISO 8601,
2026-06-26gibi yıl-ay-gün tarihini destekler - ISO 8601, RFC 3339'a göre daha çeşitli tarih gösterimlerini kapsar
- Yüzyıl:
20 - On yıl:
202 - Yıl:
2026 - Yıl-ay:
2026-06 - Ordinal gün:
2026-177 - Hafta tarihi:
2026-W26,2026-W26-5 - Temel biçim:
20260626,2026177,2026W26,2026W265
- Yüzyıl:
- Tabloda RFC 3339, ISO'ya özgü bu tarih biçimlerine izin vermez
Saat gösterimindeki farklar
- Her iki standart da
14:08:00Z,14:08:00+00:00,14:08:00.372+00:00gibi saniye düzeyinde saat ve zaman dilimi offseti içeren gösterimleri kabul eder - RFC 3339 büyük/küçük harf duyarlı değildir; bu yüzden
TveZ, sırasıylat,zolarak da yazılabilir- ISO 8601'in önceki sürümleri de büyük/küçük harf duyarlı değildi
- ISO 8601, en küçük zaman birimine ondalık bölüm eklenmesine izin verir
- Tabloda çoğunlukla tek basamaklı ondalık örnekleri yer alsa da standart keyfi hassasiyete izin verir
- Ondalık ayıracı olarak hem virgül hem nokta kabul edilir ve tüm biçimlerde birbirinin yerine kullanılabilir
- ISO 8601-1:2019, belirsizlik oluşmuyorsa yalnız saat gösteriminde
T'nin atlanmasına izin verir - ISO 8601;
14,14:08,14:08:00,140800,T14:08:00,14:08:00,372gibi kısaltılmış, temel ve virgüllü ondalık saat gösterimlerini destekler - RFC 3339,
14:08:00-00:00gibi-00:00offsetine izin verir; ancak tabloda ISO 8601 buna izin vermez
Date-Time içinde T ve ayıraçlar
- Hem RFC 3339 hem de ISO 8601,
2026-06-26T14:08:00Zve2026-06-26T14:08:00+00:00gibi Date-Time gösterimlerine izin verir - ISO 8601'in Date-Time gösteriminde
Ther zaman gereklidir- Önceki sürümlerde Date-Time içinde
T'nin atlanmasına da izin veriliyordu - Önceki sürümlerde de boşluk veya alt çizgi gibi alternatif ayıraçların eklenmesine izin verilmiyordu
- Önceki sürümlerde Date-Time içinde
- Tabloda RFC 3339, şu Date-Time varyasyonlarına izin verir
- Küçük harf
tvez:2026-06-26t14:08:00z - Boşluk ayıracı:
2026-06-26 14:08:00Z - Alt çizgi ayıracı:
2026-06-26_14:08:00Z -00:00offseti:2026-06-26T14:08:00-00:00
- Küçük harf
- ISO 8601,
2026-06-26T14,2026-06-26T14:08,2026-06-26T14:08:00,2026-177T14:08,2026-W26-5T14:08gibi kısaltılmış Date-Time gösterimlerini ve ordinal gün ya da hafta tarihi tabanlı Date-Time ifadelerini kapsar
Süreler ve aralıklar ISO 8601 merkezlidir
- Tabloda süre (Periods) biçimleri yalnızca ISO 8601 için işaretlenmiştir
- Örnek:
P1Y,P1M,P1W,P1D - Saat içeren örnekler:
PT1H,PT1M,PT1S - Birleşik örnek:
P1Y1M1DT1H1M1S - Ondalıklı örnekler:
P1.5Y,P1,5W,PT1.5S
- Örnek:
- Aralık (Ranges) biçimleri de yalnızca ISO 8601 için işaretlenmiştir
- Tarih ve süre:
2026-06-26/P1Y - Tarih ve tarih:
2026-06-26/2026-06-26 - Süre ve tarih:
P1Y/2026-06-26 - Date-Time ve süre:
2026-06-26T14:08/P1DT1H - Tekrarlı aralık:
R/2026-06-26/P1Y,R10/2026-06-26/P1Y
- Tarih ve süre:
Biçim anahtarı ve test araçları
- Biçim tablosu
%Y,%M,%D,%h,%m,%sgibi biçim anahtarları kullanır%Y: Year%M: Month%D: Day%V: Week Year%W: Week%w: Week Day%O: Ordinal Day%h: Hour%m: Minute%s: Second%u: Microsecond%n: Nanosecond%Z:+veya-içeren zaman dilimi saati%z: zaman dilimi dakikası
- Biçim denetleyicisi yalnızca girilen biçimin tablodaki biçimlerden birine karşılık gelip gelmediğini kontrol eder
- Olası tüm biçimleri denetlemez
- ISO 8601 as a Service beta test amaçlı bir servistir
- Şu anda yalnızca Date, Time, DateTime desteklenir
- Period ve Range desteklenmez
- Kaynak kodu GitHub üzerinde açıktır
1 yorum
Hacker News yorumları
Belirli bir saat dilimine göre gelecekteki bir tarih/saati belirtmenin bir yolu olmaması tuhaf. Örneğin 1 Temmuz 2030’da Londra yerel saatiyle 18:00’de bir toplantı ayarlamak isteyebilirsiniz; o arada Birleşik Krallık’ın saat dilimi kuralları nasıl değişirse değişsin, bunun “Londra’da 18:00” olarak kalması gerekir
Birleşik Krallık şu anda kabaca kasım-mart arasında Z+00:00, nisan-ekim arasında ise yaz saati Z+01:00 kullanıyor[0]; ancak 2030’dan önce Orta Avrupa Saati’ni[1] benimseyebilir, British Double Summer Time’ı[2] yeniden deneyebilir ya da yaz saatini kaldırabilir. Bu yüzden aynı “18:00”, belirli bir epoch’a göre oldukça farklı bir ana denk gelebilir
Bir takvim etkinliğine “o zamanki Londra saatiyle 18:00” koymak istiyorum, ancak 2030-07-01 18:00:00 Europe/London ifadesini standart ve birlikte çalışabilir bir biçimde göstermenin bir yolu yok
[0] https://en.wikipedia.org/wiki/British_Summer_Time
[1] https://en.wikipedia.org/wiki/Central_European_Time
[2] https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...
tzadı olarak saat dilimi eklenebiliyor; yerel saati ifade etmek için UTC ofseti tahminini de birlikte yazmak gerekiyorÖrneğin
2030-07-01 18:00:00 Europe/London,2030-07-01T18:00:00+01:00[Europe/London]olur. O tarihten önce Birleşik Krallık kuralları değişirse zaman damgası “uyumsuz” hâle gelir ve uygulama bunun nasıl ele alınacağına karar verir. Ancak köşeli parantez içindeki saat dilimi adının önüne!konursa, UTC ofsetini körü körüne izlemek yerine sorunun algılanması gerekirBu genişletilmiş zaman damgası biçimi JavaScript’in önerilen Temporal kütüphanesinde[1] de kullanılıyor;
ZonedDateTime.from()ayrıştırma işlevi[2], uyumsuz zaman damgalarında hangi tarafın öncelikli olacağınıoffsetseçeneğiyle kontrol etmeyi sağlıyor. UTC ofsetini atlayıp yalnızca saat dilimini yazmak da destekleniyor, ancak yaz saati geçişinde tekrar eden bir saatlik aralığın belirsiz olduğu uyarısını yapıyor[0] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...
[1] https://tc39.es/proposal-temporal/docs/strings.html#iana-tim...
[2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...
Ama o arada İskoçya’nın yeniden bağımsızlık referandumu yapıp Orta Avrupa Saati’ne katılması ya da Scottish Standard Time oluşturması da hayal edilemez değil
2023-11-05 01:30:00 America/New_York, iki farklı andan biri olurTakvimlerde “duvar saatinde aynı zaman” çoğunlukla istenen anlam olduğu için bu makuldür; ancak garip saatleri ele alma konusunda UI zorlukları vardır ve sözdizimine belirsizlik giderme yöntemi eklemek isteyebilirsiniz. Neyse ki bu tür geçişler genellikle gece yarısı olur, ama gerçek iş hayatında böyle bir şeye denk geldim
Yaz saati olmayan bir saat dilimindeki birini davet ederseniz, o kişinin takviminde saat kayar; uluslararası çalışma arkadaşlarının bazen bunu kabullenmesi gerekir
[0]: https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5
Yaygın tarih-saat biçimleri belirli bir anı ifade etmek için tasarlanmıştır; ancak bu durumda henüz böyle belirli bir an yoktur. Her ayın son cuma günü toplantısı, 31 Ocak’ta başlayan aylık toplantı, çeyrek sonundan iki gün önce gibi tarih/saat belirtimlerinin önemsiz olmayan bir yapıya sahip olması yaygındır
İnsanların aklına gelebilecek tüm durumları kapsayan bir standart yapmak hızla karmaşıklaşacak gibi. Basit tarih, saat ve an yeterli değilse, gerekli tüm unsurları içeren ayrı bir yapı oluşturmak dışında çare yok gibi görünüyor
ISO spesifikasyonu ücretsiz sunulmadığı için genelde RFC’yi izlemek daha iyidir; birçok açık kaynak uygulama da taslaklara dayandığından tamamen açık kaynak dostu olduğu söylenemez. Bu, açık kaynak geliştiricileri için de büyük bir yük
Gelecekteki tarihleri ele alan bir şey yapıyorsanız neredeyse her zaman duvar saati zamanı + konum saklamak istersiniz. Ne yazık ki bunun için bir standart yok. Avrupa ve ABD’de saat dilimleri epey istikrarlı olduğundan pek hissedilmeyebilir, ancak birçok bölgede saat dilimleri sık değiştiği için ofset saklamak istikrarlı değildir
5 Haziran 2026 13:30 duvar saati, Parisçoğu kişinin kastettiği şeydir; AB’nin yaz saati uygulamasıyla ilgili ne yapacağına bağlı olarak UTC+2 de olabilir, UTC+1 de. Geçmiş bir zamanı ele alan bir API ise saniye, milisaniye, mikrosaniye, nanosaniye birimlerinde POSIX zaman damgası kullanmak yeterlidiriCal de konumun başka bir saat dilimine yeniden atanması sorununu dikkate almaz. Ayrıca düzgün bir iCal dosyası, başvurduğu tüm saat dilimi verilerini içerdiğinden, tek bir tarih-saat çıktısı almak istediğinizde zahmetlidir
[1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
2026-06-05T13:30+0200[Europe/Paris]https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...
Standartlarda sıkça göz ardı edilen kısım süre gösterimidir
http://xml.coverpages.org/ISO-FDIS-8601.pdf içindeki 5.5.4.2 “Representation of time-interval by duration only”, sayfa 21’e bakabilirsiniz. Statik dillerdeki JSON ayrıştırıcılarının bir alanı süre olarak tanımlayıp geçerli biçimde serileştirebilmesini sağlaması güzel olurdu
Crystal için öneri örneği burada: https://github.com/crystal-lang/crystal/issues/11942
Örneğin 15 gün 5 saat 20 saniye
P15DT5H0M20S, 7 hafta iseP7Wolurdurationtanımına da başvurulabilirÖrneğin
"duration": { "days": 15, "hours": 5, "seconds": 20 }gibi yazarsanız JSON ayrıştırıcısının verinin anlamını anlaması gerekmez; bunu girdi doğrulayıcı üstlenir. Zaten JSON bu veriyi hangi şekilde temsil ederse etsin, başarısız olma ihtimali olan bir dönüştürme adımı gerekecektirRFC 3339 ve ISO 8601, amaçları örtüşen birçok yinelenen tarih-saat biçimi içerirken, tüm sistemlerde en çok kullanılan ve fazlasıyla bariz olan
2023-09-01 15:30:59biçiminin ikisinde de yer almaması “komik”Ayrıca iki standart da milattan önceki tarihler ile
9999-12-31sonrasındaki veya-9999-01-01öncesindeki tarihlerin nasıl gösterileceği konusunda çok belirsiz; yaygın kütüphaneler de çoğunlukla bunları hiç işleyemiyor. İşleseler bile00-01-01davranışı fiilen tanımsız sayılacak düzeydeGregoryen takvim, MÖ 1’den sonraki yıl MS 1 olduğu için tuhaf; uzman astronomi yazılımları dışında neredeyse tüm yazılımlar yakın gelecekteki Unix zaman aralığının dışını düzgün ele alamıyor. İmparator Augustus’un doğum-ölüm yılları gibi metin olarak saklamanın bile yeterli olduğu konuları standart açıkça tanımlasa yeter
T’nin boşlukla değiştirilebildiği ISO 8601 gibi basit bir kısıt eklemek yeterli. RFC 3339 da çok daha uzun bir yolla benzerini yapar2023-09-01 15:30:59’un en çok kullanılan tarih-saat biçimi olduğundan emin olmak da zor. En çok kullanılan dil Çince ve2023年9月1日gibi kendine özgü ayraçlar yaygınISO 8601, karşılıklı mutabakat varsa 1582’den önceki veya 9999’dan sonraki yıllara da izin verir. 4 haneye sığmıyorsa başına tek bir işaret karakteri eklenmelidir. Bu tür tarihlerle anlamlı olarak yapılabilecek şey az olduğundan genellikle desteklenmez, ancak özellikle C’den bağımsız uygulanmış kütüphanelerde bunları ayrıştıran örnekleri epey gördüm
00-01-01, MÖ 1 yılı 1 Ocak olarak tanımlıdır. ISO 8601, yıl numaralarının ileriye/geriye uzatılmış Gregoryen takvimi (proleptic Gregorian calendar) izlediğini açıkça belirttiği için negatif sonsuza kadar ekstrapole edilirBoşluk olmayan bir karaktere neden ihtiyaç duyulduğunu anlıyorum, ama en azından alt çizgi veya nokta da kullanılabilirdi. Ayrıca bir metin dizisi olmasına rağmen yıl aralığını dört haneyle sınırlayıp biçimin evrenselliğinden neden ödün verildiğini de bilmiyorum
6 haneli yıl, geleceğe dönük görünmek için, gerçekte ortaya çıkmayacak bir soruna çözüm gibi geliyor. Mevcut teknolojinin ya da toplumsal normların 8000 yıl sürmesi mümkün değil
ISO 8601'in U+2010 HYPHEN ve U+2212 MINUS kullandığı, bu karakterlerin bulunmadığı karakter kümelerinde ise U+2D HYPHEN-MINUS kullanılması gerektiği açıklaması yanlış
Gerçekte ISO 8601, hedef karakter kümesi ISO/IEC 646 tabanlıysa her iki durumda da hyphen-minus karakterinin kullanılması gerektiğini açıkça belirtir. Buna Unicode kesinlikle dahildir. Biraz belirsizlik olsa da Unicode için yorum nettir; 646'nın standart eşlemesini belirleyerek 646 tabanlı diğer karakter kümeleriyle uyumluluğu garanti etmeye çalışan dolaylı bir yöntem gibi görünüyor
İçerik şu şekildedir: “Tarih ve saat gösterimlerinde kullanılan tüm karakterler, ‘hyphen’, ‘minus’, ‘plus-minus’ dışında ISO/IEC 646 repertuarına aittir. ISO/IEC 646 tabanlı karakter repertuarı kullanan ortamlarda hem ‘hyphen’ hem de ‘minus’, ‘hyphen-minus’ olarak eşlenmelidir”
Unicode, ISO 8859 tabanlıdır ve ISO 8859 da ISO 646 tabanlı olduğundan, Unicode karakter kümesinde U+2D hyphen-minus kullanılmasının amaçlandığı anlaşılıyor
Windows'ta iki nokta üst üste özel karakter olduğu için dosya adlarına tarih ve saat koyarken RFC 3339'a uygun bir yöntem olmaması sık sık can sıkıyor
Tarihte tire kullanırken iki nokta üst üsteyi çıkarmanın da ISO 8601'e uygun olabilmesi iyi olurdu. Örneğin
20230831T1510-0500uyumludur ve dosya adında kullanılabilir, ancak2023-08-31T1510-0500ve benzeri varyasyonlar uyumlu değildir. Ek olarak PowerShell'inGet-Datefonksiyonu, tire ve iki nokta üst üste içermeyen ilk zaman damgasını anlayamazBu konu için çok iyi bir görselleştirme
Tarih ve saat bölümünü ayırırken
Tyerine boşluk ya da alt çizgiyi tercih ediyorum, ancak yalnızca ISO 8601 işleyen sistemlerle sorun yaşamamak ve tutarlılık için çoğunluklaTkullanmaya devam ediyorumTyi tercih ederim. Böyle bir dizgiyi kazaraTye göre bölme ihtimaliniz olmazİki şeyi merak ediyorum. Birincisi, 6 haneli yılın dayanağı nedir? Bugün tasarlanan herhangi bir sistemin 100.000 yılında var olması pek mümkün değil, değil mi
İkincisi, ISO 8601 yaygın; peki RFC 3339 da gerçek sistemlerde çok kullanılıyor ve benimsenmiş durumda mı?
timepaketi ve Rust'ınChronosu RFC 3339 ile çalışmak için yerleşik araçlara sahip, ancak RFC 8601 için değilHatırladığım kadarıyla RFC 8601'de RFC 3339'da olmayan belirsizlik sorunları vardı ve Python'ın da bu yüzden tarihleri gidiş-dönüş dönüştürmede sorun yaşadığını biliyorum
Saat diliminin iki nokta üst üste olmadan dört hane olarak belirtildiği bir biçim yok, ama
date +%z±NNNNdöndürür%:zvar. Bununla ilgili olarakdatee varsayılan olarak şöyle çıktı vermeyi de öğretebilirsiniz: https://gist.github.com/d081dad407432d53172e30d0d35c39db$ date2023-08-31T11:15:00-07:00±NNNN, “temel biçim”in parçası olarak kullanıldığında iki nokta üst üste olmadan da geçerlidir. Yani tüm biçimin hiçbir yerinde tire ya da iki nokta üst üste olmamalıdırDolayısıyla şu ikisi eşdeğerdir ve ikisi de geçerlidir:
2023-09-01T09:40:01+08:0020230901T094001+0800