Perbandingan RFC 3339 dan ISO 8601

 (ijmacd.github.io)
3 poin oleh GN⁺ 2023-09-01 | 1 komentar | Bagikan ke WhatsApp
  • Saat menangani notasi tanggal dan waktu, RFC 3339 lebih mirip subset sempit yang mudah digunakan di web dan internet, sedangkan ISO 8601-1:2019 mencakup kumpulan format yang jauh lebih luas
  • Cakupan perbandingan dibatasi pada ISO 8601-1:2019, dan ekspresi tambahan seperti musim, himpunan, pembatasan ketidakpastian, serta aritmetika tanggal dalam ISO 8601-2:2019 belum tercermin dalam tabel
  • Kedua standar sama-sama mencakup format tanggal dan waktu dasar yang banyak digunakan, seperti 2026-06-26, 14:08:00Z, 2026-06-26T14:08:00Z, dan offset +00:00
  • ISO 8601 mencakup hingga abad, dekade, hari ordinal, tanggal minggu, waktu ringkas, koma sebagai tanda desimal, periode (P1Y), dan rentang (2026-06-26/P1Y), tetapi sebagian besar dikecualikan dari RFC 3339 dalam tabel
  • Dalam notasi Date-Time, perbedaan seperti pemisah T, huruf besar/kecil, dan offset -00:00 menjadi titik yang menentukan kompatibilitas parser di praktik nyata

Cakupan dan asumsi perbandingan

  • Tabel format bukan daftar lengkap
  • Standar yang menjadi target adalah ISO 8601-1:2019
    • Ada perbedaan penting dibanding edisi sebelumnya dan draf
  • ISO 8601-2:2019 mencakup ekspresi tambahan, tetapi belum tercermin di halaman ini
    • Kelompok sub-tahun, misalnya musim
    • Unit pengelompokan
    • Himpunan
    • Pembatasan ketidakpastian
    • Aritmetika tanggal
  • RFC 3339 menyarankan bahwa dalam standar turunan, T dapat diganti dengan karakter lain, tetapi contohnya hanya memberikan karakter spasi
  • Masing-masing standar mendefinisikan format untuk tujuan tertentu, dan format di luar itu tidak direkomendasikan

ISO 8601 lebih luas dalam notasi tanggal

  • RFC 3339 dan ISO 8601 sama-sama mendukung tanggal tahun-bulan-hari seperti 2026-06-26
  • ISO 8601 menangani ekspresi tanggal yang lebih beragam dibanding RFC 3339
    • Abad: 20
    • Dekade: 202
    • Tahun: 2026
    • Tahun-bulan: 2026-06
    • Hari ordinal: 2026-177
    • Tanggal minggu: 2026-W26, 2026-W26-5
    • Format dasar: 20260626, 2026177, 2026W26, 2026W265
  • Dalam tabel, RFC 3339 tidak mengizinkan format tanggal khusus ISO di atas

Perbedaan dalam notasi waktu

  • Kedua standar sama-sama mengizinkan waktu hingga detik dan offset zona waktu seperti 14:08:00Z, 14:08:00+00:00, dan 14:08:00.372+00:00
  • RFC 3339 tidak membedakan huruf besar/kecil, sehingga T dan Z masing-masing dapat ditulis sebagai t dan z
    • Edisi ISO 8601 sebelumnya juga tidak membedakan huruf besar/kecil
  • ISO 8601 dapat menambahkan bagian pecahan pada nilai waktu terkecil
    • Tabel terutama menampilkan contoh dengan satu digit pecahan, tetapi standarnya mengizinkan presisi arbitrer
    • Koma dan titik sama-sama diizinkan sebagai pemisah desimal, dan dapat saling menggantikan di semua format
  • ISO 8601-1:2019 mengizinkan penghilangan T dalam ekspresi waktu saja jika tidak ambigu
  • ISO 8601 mendukung ekspresi waktu ringkas, dasar, dan dengan koma desimal seperti 14, 14:08, 14:08:00, 140800, T14:08:00, dan 14:08:00,372
  • RFC 3339 mengizinkan offset -00:00 seperti 14:08:00-00:00, tetapi dalam tabel ISO 8601 tidak mengizinkannya

T dan pemisah dalam Date-Time

  • RFC 3339 dan ISO 8601 sama-sama mengizinkan Date-Time seperti 2026-06-26T14:08:00Z dan 2026-06-26T14:08:00+00:00
  • Dalam ekspresi Date-Time ISO 8601, T selalu diperlukan
    • Edisi sebelumnya juga mengizinkan penghilangan T dalam Date-Time
    • Bahkan pada edisi sebelumnya, penyisipan karakter pengganti seperti spasi atau garis bawah tidak diizinkan
  • Dalam tabel, RFC 3339 mengizinkan variasi Date-Time berikut
    • Huruf kecil t dan z: 2026-06-26t14:08:00z
    • Pemisah spasi: 2026-06-26 14:08:00Z
    • Pemisah garis bawah: 2026-06-26_14:08:00Z
    • Offset -00:00: 2026-06-26T14:08:00-00:00
  • ISO 8601 menangani Date-Time ringkas dan Date-Time berbasis hari ordinal/tanggal minggu seperti 2026-06-26T14, 2026-06-26T14:08, 2026-06-26T14:08:00, 2026-177T14:08, dan 2026-W26-5T14:08

Periode dan rentang berpusat pada ISO 8601

  • Dalam tabel, format periode (Periods) hanya dicentang untuk ISO 8601
    • Contoh: P1Y, P1M, P1W, P1D
    • Contoh dengan waktu: PT1H, PT1M, PT1S
    • Contoh kombinasi: P1Y1M1DT1H1M1S
    • Contoh pecahan: P1.5Y, P1,5W, PT1.5S
  • Format rentang (Ranges) juga hanya dicentang untuk ISO 8601
    • Tanggal dan periode: 2026-06-26/P1Y
    • Tanggal dan tanggal: 2026-06-26/2026-06-26
    • Periode dan tanggal: P1Y/2026-06-26
    • Date-Time dan periode: 2026-06-26T14:08/P1DT1H
    • Rentang berulang: R/2026-06-26/P1Y, R10/2026-06-26/P1Y

Kunci format dan alat uji

  • Tabel format menggunakan kunci format seperti %Y, %M, %D, %h, %m, dan %s
    • %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: jam zona waktu yang mencakup + atau -
    • %z: menit zona waktu
  • Pemeriksa format hanya memastikan apakah format input termasuk dalam format di tabel
    • Tidak memeriksa semua format yang mungkin
  • ISO 8601 as a Service adalah layanan untuk pengujian beta
    • Saat ini hanya mendukung Date, Time, dan DateTime
    • Period dan Range tidak didukung
  • Sumbernya tersedia di GitHub

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-01
Pendapat di Hacker News

  • Aneh bahwa tidak ada cara untuk menentukan tanggal/waktu di masa depan berdasarkan zona waktu tertentu. Misalnya, kita mungkin ingin menjadwalkan rapat pada 1 Juli 2030 pukul 18.00 waktu lokal London, dan apa pun perubahan aturan zona waktu Inggris di antaranya, itu harus tetap berarti “pukul 18.00 di London”
    Saat ini Inggris kira-kira menggunakan Z+00:00 pada November–Maret dan waktu musim panas Z+01:00 pada April–Oktober[0], tetapi sebelum 2030 bisa saja mengadopsi Waktu Eropa Tengah[1], mencoba lagi British Double Summer Time[2], atau menghapus waktu musim panas. Jadi “pukul 18.00” yang sama bisa sangat berbeda jika dilihat berdasarkan epoch tertentu
    Saya ingin memasukkan “pukul 18.00 menurut waktu London saat itu” ke acara kalender, tetapi tidak ada cara standar dan interoperabel untuk merepresentasikan 2030-07-01 18:00:00 Europe/London
    [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...

    • Ada dokumen draf untuk format seperti itu, yaitu IXDTF (Internet Extended Date/Time Format)[0]. Setelah string RFC 3339, zona waktu bisa ditambahkan sebagai nama tz di dalam tanda kurung siku, dan untuk mengekspresikan waktu lokal, perkiraan offset UTC juga harus ditulis bersama
      Misalnya 2030-07-01 18:00:00 Europe/London menjadi 2030-07-01T18:00:00+01:00[Europe/London]. Jika aturan Inggris berubah sebelumnya, timestamp itu menjadi “tidak cocok”, dan aplikasi yang menentukan cara menanganinya. Namun jika menaruh ! sebelum nama zona waktu di dalam tanda kurung siku, masalah tersebut harus dideteksi, bukan sekadar mengikuti offset UTC secara membuta
      Format timestamp yang diperluas ini juga digunakan dalam pustaka Temporal yang diusulkan untuk JavaScript[1], dan fungsi parsing ZonedDateTime.from()[2] memungkinkan opsi offset untuk mengontrol mana yang diprioritaskan pada timestamp yang tidak cocok. Menghilangkan offset UTC dan hanya menulis zona waktu juga didukung, tetapi diperingatkan bahwa interval satu jam yang berulang saat transisi waktu musim panas bersifat ambigu
      [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...
    • Sebenarnya sepertinya dibutuhkan informasi yang lebih spesifik daripada zona waktu. Misalnya, jika ingin bertemu pada 1 Juli 2030 pukul 18.00 di Glasgow, Skotlandia, bukan London, saat ini Glasgow berada di zona waktu Europe/London
      Namun bukan hal yang sepenuhnya mustahil membayangkan bahwa di antaranya Skotlandia kembali mengadakan referendum kemerdekaan lalu bergabung dengan Waktu Eropa Tengah, atau membuat Scottish Standard Time
    • Jebakan dari ekspresi seperti ini adalah munculnya timestamp yang ambigu atau tidak mungkin. 2023-11-05 01:30:00 America/New_York bisa berarti salah satu dari dua waktu yang berbeda
      Dalam kalender, “waktu yang sama menurut jam dinding” biasanya memang makna yang diinginkan, jadi itu masuk akal, tetapi ada kesulitan UI untuk menangani waktu-waktu aneh, dan mungkin kita ingin memasukkan cara menghilangkan ambiguitas ke dalam sintaks. Untungnya transisi seperti ini biasanya terjadi tengah malam, tetapi saya pernah melihat hal seperti ini dalam pekerjaan nyata
      Jika mengundang orang dari zona waktu tanpa waktu musim panas, waktu di kalender orang itu akan berubah-ubah, dan terkadang rekan internasional harus menerima hal ini
    • Di dunia kalender, iCal sudah mendukungnya. Tanggal-waktu tanpa zona waktu hanya berarti waktu lokal[0]
      [0]: https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5
    • Informasi yang dibutuhkan adalah tiga hal: tanggal, lokasi, dan waktu lokal. Yang sebenarnya diinginkan mungkin bukan zona waktu. Perlu dipikirkan apa yang harus dilakukan jika suatu tempat selain London berpindah ke zona waktu lain
      Format tanggal-waktu yang umum dibuat untuk merepresentasikan suatu titik waktu tertentu, tetapi dalam kasus ini titik waktu tertentu itu belum ada. Spesifikasi tanggal/waktu dengan struktur yang tidak sepele itu umum, seperti rapat pada Jumat terakhir setiap bulan, rapat bulanan yang dimulai pada 31 Januari, atau dua hari sebelum akhir kuartal
      Jika ingin membuat standar yang mencakup semua kasus yang bisa dibayangkan orang, tampaknya itu akan cepat menjadi rumit. Jika tanggal sederhana, waktu, dan instan tidak cukup, sepertinya satu-satunya jalan adalah membuat struktur terpisah yang memuat semua elemen yang diperlukan

  • Karena spesifikasi ISO tidak tersedia gratis, biasanya lebih baik mengikuti RFC, dan banyak implementasi open source juga berbasis draf, sehingga sulit disebut sepenuhnya ramah open source. Ini juga menjadi beban besar bagi developer open source
    Jika membuat sesuatu yang menangani tanggal di masa depan, hampir selalu kita ingin menyimpan waktu jam dinding + lokasi. Sayangnya tidak ada standar untuk ini. Eropa dan AS memiliki zona waktu yang cukup stabil sehingga masalah ini mungkin tidak terlalu terasa, tetapi di banyak wilayah zona waktu sering berubah, sehingga menyimpan offset tidak stabil
    5 Juni 2026 pukul 13:30 jam dinding, Paris adalah maksud kebanyakan orang, dan bergantung pada keputusan Uni Eropa soal daylight saving time, itu bisa saja UTC+2 atau UTC+1. Jika API menangani waktu lampau, cukup gunakan timestamp POSIX dalam satuan detik, milidetik, mikrodetik, atau nanodetik

    • iCalendar adalah standar RFC untuk hal ini[1]. Namun, ketika waktu berubah karena daylight saving time, sebagian waktu memiliki dua representasi, dan sebagian waktu tidak dapat direpresentasikan dalam format ini
      iCal juga tidak mempertimbangkan masalah ketika sebuah lokasi dialihkan ke zona waktu lain. Selain itu, file iCal yang benar menyertakan semua data zona waktu yang dirujuknya, sehingga merepotkan jika hanya ingin menampilkan satu tanggal-waktu saja
      [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
    • Ada draf standar bernama IXDTF yang memperluas RFC 3339 dengan memasukkan nama zona waktu IANA di dalam tanda kurung siku: 2026-06-05T13:30+0200[Europe/Paris]
      https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...

  • Bagian yang sering diabaikan dalam standar adalah representasi durasi
    Lihat 5.5.4.2 “Representation of time-interval by duration only”, halaman 21 di http://xml.coverpages.org/ISO-FDIS-8601.pdf. Akan bagus jika parser JSON di bahasa statis bisa mendefinisikan field sebagai durasi dan menserialisasikannya dalam format yang valid
    Contoh proposal untuk Crystal ada di sini: https://github.com/crystal-lang/crystal/issues/11942
    Misalnya, 15 hari 5 jam 20 detik menjadi P15DT5H0M20S, dan 7 minggu menjadi P7W

    • Sebagai alternatif, bisa juga merujuk definisi duration dalam ABNF di Lampiran A RFC 3339
    • Saya tidak mengerti mengapa data yang bisa distrukturkan ingin disimpan dalam bentuk string
      Misalnya, jika ditulis seperti "duration": { "days": 15, "hours": 5, "seconds": 20 }, parser JSON tidak perlu memahami makna datanya, dan validator input bisa menanganinya. Bagaimanapun JSON merepresentasikan data ini, tetap diperlukan tahap konversi yang berpotensi gagal

  • Yang “lucu” dari RFC 3339 dan ISO 8601 adalah keduanya memuat banyak format tanggal-waktu yang tumpang tindih tujuannya, tetapi keduanya tidak memuat format yang paling banyak dipakai di semua sistem dan sangat jelas, yaitu 2023-09-01 15:30:59
    Selain itu, kedua standar sama-sama sangat tidak jelas tentang cara merepresentasikan tanggal SM dan tanggal setelah 9999-12-31 atau sebelum -9999-01-01, dan library umum biasanya sama sekali tidak bisa menanganinya. Kalaupun bisa, perilaku 00-01-01 pada dasarnya berada pada tingkat tidak terdefinisi
    Kalender Gregorian terasa aneh karena tahun setelah 1 SM adalah 1 M, dan selain software astronomi profesional, hampir semua software tidak mampu menangani rentang waktu Unix di luar masa depan dekat dengan benar. Bahkan untuk hal yang cukup disimpan sebagai string, seperti tahun lahir dan wafat Kaisar Augustus, standar seharusnya mendefinisikannya dengan jelas

    • ISO 8601 mengizinkan format itu jika ada kesepakatan bersama. “Kesepakatan bersama” terdengar muluk, tetapi cukup dengan batasan sederhana seperti ISO 8601 yang memungkinkan T diganti dengan spasi. RFC 3339 juga melakukan hal serupa dengan cara yang jauh lebih bertele-tele
      Sulit juga memastikan apakah 2023-09-01 15:30:59 benar-benar format tanggal-waktu yang paling banyak dipakai. Bahasa yang paling banyak digunakan adalah bahasa Mandarin, dan pemisah khas seperti 2023年9月1日 umum dipakai
      ISO 8601 mengizinkan tahun sebelum 1582 atau setelah 9999 jika ada kesepakatan bersama. Jika tidak muat dalam 4 digit, harus ditambahkan satu karakter tanda di depannya. Tanggal seperti ini jarang didukung karena tidak banyak hal bermakna yang bisa dilakukan dengannya, tetapi saya cukup sering melihat library yang mem-parse-nya, terutama library yang diimplementasikan independen dari C
      00-01-01 didefinisikan sebagai 1 Januari tahun 1 SM. ISO 8601 menjelaskan bahwa penomoran tahun mengikuti kalender Gregorian proleptik (proleptic Gregorian calendar), sehingga diekstrapolasikan hingga tak hingga negatif
    • Format yang dipisahkan dengan spasi jauh lebih mudah dibaca. Setelah hampir 20 tahun mematuhi standar, belakangan ini saya mulai mengabaikan keduanya demi format pemisah spasi yang lebih baik
      Saya mengerti alasan mengapa dulu diperlukan karakter selain spasi, tetapi setidaknya bisa saja menggunakan garis bawah atau titik. Dan karena ini string, saya juga tidak mengerti mengapa rentang tahun dibatasi empat digit sehingga mengorbankan universalitas format

  • Tahun 6 digit terasa seperti solusi untuk masalah yang sebenarnya tidak akan terjadi, hanya agar terlihat berorientasi masa depan. Teknologi atau norma sosial saat ini tidak mungkin bertahan 8000 tahun

    • Komputer tidak hanya dipakai untuk hal-hal yang berkaitan dengan hari ini. Misalnya, jika menjalankan perhitungan iklim yang sangat panjang, memang error karena tanggal bisa saja diabaikan, tetapi bukankah lebih baik jika error itu tidak terjadi?
    • Baik 5 digit maupun 7 digit, selama jumlah digitnya bisa disepakati kedua pihak sebelum mulai berkomunikasi, itu bisa digunakan. Bagian 2 standar bahkan memuat contoh tahun 10 digit
    • Tahun 6 digit adalah solusi untuk masalah yang sudah ada sekarang. Bayangkan seorang geolog sedang menyimulasikan pergerakan benua

  • Penjelasan bahwa ISO 8601 memakai U+2010 HYPHEN dan U+2212 MINUS, lalu harus memakai U+2D HYPHEN-MINUS pada set karakter yang tidak memiliki karakter tersebut, itu keliru
    ISO 8601 yang sebenarnya menyatakan bahwa jika set karakter target berbasis ISO/IEC 646, maka dalam kedua kasus harus memakai karakter hyphen-minus. Unicode jelas termasuk di sini. Memang ada sedikit ambiguitas, tetapi di Unicode tafsirnya jelas, dan ini tampaknya cara tidak langsung untuk menjamin kompatibilitas dengan set karakter lain berbasis 646 dengan menetapkan pemetaan kanonis dari 646

    • Paragraf terkait ada di ISO 8601-1:2019 §3.2.1
      Isinya kira-kira: “Semua karakter yang digunakan dalam representasi tanggal dan waktu, kecuali ‘hyphen’, ‘minus’, dan ‘plus-minus’, termasuk dalam repertoar ISO/IEC 646. Dalam lingkungan yang memakai repertoar karakter berbasis ISO/IEC 646, ‘hyphen’ dan ‘minus’ keduanya harus dipetakan ke ‘hyphen-minus’”
      Karena Unicode berbasis ISO 8859 dan ISO 8859 berbasis ISO 646, tampaknya memang maksudnya adalah memakai U+2D hyphen-minus dalam set karakter Unicode

  • Di Windows, titik dua adalah karakter khusus, jadi sering terasa mengganggu bahwa tidak ada cara yang sesuai RFC 3339 saat memasukkan tanggal dan waktu ke nama file
    Akan bagus kalau tetap bisa mematuhi ISO 8601 dengan memakai tanda hubung pada tanggal tetapi menghilangkan titik dua. Misalnya 20230831T1510-0500 sesuai dan bisa dipakai sebagai nama file, tetapi 2023-08-31T1510-0500 dan variasi serupa tidak. Sebagai tambahan, fungsi Get-Date di PowerShell tidak memahami timestamp pertama yang tanpa tanda hubung dan titik dua

    • Menghapus titik dua aman dan tidak membuat tanggal maupun date-time RFC 3339 menjadi ambigu. Titik dua selalu bisa dipulihkan tanpa kehilangan informasi
    • Saya tidak tahu Windows punya masalah seperti ini. MacOS juga punya masalah lain terkait titik dua dalam nama file. Kalau dua dari tiga sistem operasi yang paling banyak dipakai punya masalah ini, berarti memang ada kekurangan pemikiran dalam desainnya

  • Visualisasi yang sangat bagus untuk topik ini
    Saat memisahkan bagian tanggal dan waktu, saya lebih suka spasi atau garis bawah daripada T, tetapi untuk menghindari masalah dengan parser yang hanya menangani ISO 8601 dan demi konsistensi, biasanya tetap memakai T

    • Saya lebih suka T. String seperti ini tidak akan secara tidak sengaja dipecah berdasarkan T

  • Ada dua hal yang membuat saya penasaran. Pertama, apa dasar untuk tahun 6 digit? Sistem apa pun yang kita rancang sekarang rasanya tidak mungkin masih ada pada tahun 100.000
    Kedua, ISO 8601 sudah tersebar luas, tetapi apakah RFC 3339 juga banyak dipakai dan diadopsi dalam sistem nyata?

    • Melihat berapa lama waktu yang dibutuhkan untuk benar-benar lepas dari teknologi lama, saya tidak akan terkejut kalau pada tahun 100.000 komputer kuantum masih mengemulasikan x86
    • Ketika sebuah library mengatakan ISO 8601, 90% biasanya tidak benar-benar mengimplementasikan bagian-bagian ISO 8601 yang lebih rumit
    • Paket resmi time di Golang dan Chrono di Rust punya tool bawaan untuk menangani RFC 3339, tetapi bukan untuk RFC 8601
      Seingat saya, RFC 8601 punya masalah ambiguitas yang tidak ada di RFC 3339, dan Python juga sempat bermasalah dengan konversi bolak-balik tanggal karena ini
    • Kalau untuk tool ilmiah, bisa saja ingin merepresentasikan tanggal di masa depan yang sangat jauh
    • Y10k (:

  • Tidak ada format yang menetapkan zona waktu sebagai empat digit tanpa titik dua, tetapi date +%z mengembalikan ±NNNN

    • Untungnya ada %:z. Terkait itu, date juga bisa diajari agar secara default mencetak seperti ini: https://gist.github.com/d081dad407432d53172e30d0d35c39db
      $ date
      2023-08-31T11:15:00-07:00
    • ±NNNN valid tanpa titik dua jika dipakai sebagai bagian dari “format dasar”. Artinya, di seluruh format tidak boleh ada tanda hubung maupun titik dua
      Jadi dua berikut ini setara dan semuanya valid:
      2023-09-01T09:40:01+08:00
      20230901T094001+0800