"05/03/2024" berarti 5 Maret di Indonesia, tapi 3 Mei di Amerika Serikat. Perbedaan konvensi penulisan ini saja menyebabkan lebih banyak kesalahan nyata dalam menghitung selisih tanggal dibanding tahun kabisat dan zona waktu digabung jadi satu, karena tanggal yang "salah dibaca" tetap terlihat sah.
DD/MM/YYYY vs MM/DD/YYYY
Di Indonesia, seperti kebanyakan negara lain, tanggal ditulis lebih dulu: 05/03/2024 berarti 5 Maret. Di Amerika Serikat, bulan ditulis lebih dulu — string yang sama di sana berarti 3 Mei. Jika tanggal dari API atau spreadsheet Amerika dibaca dengan urutan Indonesia, selisih tanggal yang dihitung bisa salah berminggu-minggu tanpa ada error kode sama sekali.
Format tanpa ambiguitas: ISO 8601
Penulisan 2024-03-05 (tahun-bulan-tanggal) dibaca sama di negara mana pun, itulah sebabnya format ini menjadi standar di API, basis data, dan log sistem. Kalau format bisa dipilih saat bertukar tanggal antarsistem, ISO 8601 menghilangkan masalah ini selamanya.
Zona waktu dan batas hari
Jika tanggal mencakup waktu, bukan hanya hari, perbedaan zona waktu bisa menggeser hasil hitungan hari sebanyak satu: pukul 23:30 di Jakarta dan 16:30 pada saat yang sama di London bisa jatuh pada hari kalender berbeda tergantung zona yang digunakan untuk menghitung.
Untuk apa ini dibutuhkan
- Menghitung jumlah hari yang tepat hingga tenggat waktu atau sejak tanggal mulai proyek.
- Memeriksa apakah kontrak sewa, langganan, atau garansi masih berlaku.
- Menangkap tanggal yang salah dibaca formatnya sebelum merusak sebuah laporan.
Kenapa "selisih bulan" tidak punya satu jawaban yang pasti benar
Mengurangi satu bulan dari 31 Maret memberi hasil yang ambigu — tanggal 31 Februari tidak ada, jadi sebagian sistem membulatkan ke 28 Februari sementara yang lain memindahkan hari berlebih ke 3 Maret. Kedua pendekatan sama-sama masuk akal tapi tidak sepakat, hal yang perlu diingat kalau hasilnya berbeda dari alat lain.