10 Bug Terkait Tanggal & waktu yang Pernah Merugikan Perusahaan Besar

Dalam project terakhir saya, seringkali menemukan beberapa bug yang terkait tanggal dan waktu. Bug tersebut cukup sepeleh namun jika sampai lolos ke prod maka bikin repot banyak orang dan tentu saja bakalan butuh effort lebih untuk fixnya.

Dalam dunia software engineering, waktu bukanlah sekadar angka di layar. Ia adalah variabel kompleks yang penuh jebakan, mulai dari zona waktu, tahun kabisat, hingga daylight saving. Kesalahan kecil dalam mengelola waktu dapat memicu bencana besar, menyebabkan kerugian finansial, merusak reputasi, dan menciptakan kekacauan massal.

Oleh karena itu saya ingin membahas 10 bug terkait tanggal dan waktu yang pernah terjadi pada perusaan besar. Sehingga kita dapat belajar untuk mencegah hal tersebut terjadi pada project yang kita pegang.

1. Kesalahan Format Tanggal (Date Format Bug)

• Kasus: Raksasa ritel Inggris, Tesco (2010), mengalami mimpi buruk. Sistem pemrosesan pesanan online mereka salah menginterpretasikan format tanggal. Di Inggris, format yang umum adalah DD/MM/YYYY (Hari/Bulan/Tahun), namun parser sistem membaca beberapa input sebagai MM/DD/YYYY (Bulan/Hari/Tahun).
• Masalah: Kekacauan terjadi pada tanggal 1 hingga 12 setiap bulan. Sebagai contoh, pesanan yang dijadwalkan untuk 4 April 2010 (04/04/2010) aman. Namun, pesanan untuk 5 April 2010 (05/04/2010) bisa jadi dibaca sebagai 4 Mei 2010. Lebih parah lagi, pesanan untuk tanggal 13 April 2010 (13/04/2010) langsung ditolak oleh sistem karena tidak ada bulan ke-13. Akibatnya, ribuan pesanan pengiriman dibatalkan secara sepihak oleh sistem tanpa pemberitahuan yang jelas.
• Dampak: Ribuan transaksi gagal total, pelanggan marah, dan reputasi Tesco sebagai peritel online yang andal tercoreng. Tim harus bekerja ekstra untuk mengatasi keluhan dan memproses ulang pesanan secara manual.
• Pencegahan:
  • Lakukan pengujian input tanggal dengan berbagai format lokal dan internasional.
  • Pastikan aplikasi konsisten menggunakan satu format tanggal standar di backend, seperti ISO 8601 (YYYY-MM-DD).
  • Lakukan pengujian dengan mengubah pengaturan bahasa dan regional (locale) pada sistem operasi dan browser.

2. Kekacauan Zona Waktu (Timezone Bug)

• Kasus: Microsoft Outlook (2012) menyebabkan kebingungan penjadwalan global. Sebuah bug muncul ketika seorang pengguna di satu zona waktu menjadwalkan rapat untuk peserta di zona waktu lain. Server salah menangani konversi antar zona waktu.
• Masalah: Bayangkan seorang manajer di London (GMT) menjadwalkan rapat pada pukul 14:00 waktu setempat. Seharusnya, untuk tim di New York (EST, GMT-5), undangan tersebut muncul pada pukul 09:00. Namun, bug ini menyebabkan beberapa undangan tetap menampilkan pukul 14:00 tanpa konversi, atau melakukan konversi yang salah. Akibatnya, tim di seluruh dunia bergabung ke rapat pada waktu yang berbeda-beda, bahkan ada yang terlewat sama sekali.
• Dampak: Ribuan rapat bisnis dan konferensi telepon menjadi kacau, menyebabkan hilangnya produktivitas dan frustrasi di kalangan perusahaan yang mengandalkan Outlook.
• Pencegahan:
  • Simulasikan pengguna yang membuat dan menerima acara dari berbagai zona waktu.
  • Praktik terbaik: Selalu simpan semua data waktu dalam format UTC (Coordinated Universal Time) di database. Konversi ke zona waktu lokal hanya dilakukan pada sisi klien (frontend) saat akan ditampilkan kepada pengguna.
  • Uji bagaimana sistem bereaksi saat zona waktu perangkat diubah secara real-time.

3. Jebakan Daylight Saving Time (DST Bug)

• Kasus: Pengguna iPhone (2010-2012) di seluruh dunia dikejutkan oleh alarm yang tidak bisa diandalkan. Saat transisi Daylight Saving Time (DST) terjadi, di mana jam dimajukan atau dimundurkan satu jam, logika alarm pada iOS mengalami kegagalan.
• Masalah: Bug ini menyebabkan alarm berbunyi satu jam lebih awal atau satu jam lebih lambat dari yang seharusnya. Masalah ini sangat membingungkan karena hanya memengaruhi alarm yang tidak berulang (non-recurring). Banyak orang terlambat bangun kerja, sementara yang lain terpaksa bangun satu jam lebih awal. Masalah ini terjadi berulang kali selama beberapa tahun sebelum akhirnya diperbaiki sepenuhnya.
• Dampak: Keterlambatan massal terjadi di berbagai negara. Dilaporkan ada pilot dan awak kabin yang terlambat, menyebabkan penundaan bahkan pembatalan penerbangan. Kepercayaan terhadap fungsi dasar iPhone pun sempat menurun.
• Pencegahan:
  • Buat test case spesifik untuk hari transisi DST (saat jam maju dan mundur).
  • Gunakan database zona waktu yang selalu diperbarui (seperti IANA Time Zone Database) yang mendukung aturan DST, contohnya “America/New_York”.
  • Pastikan semua library atau framework waktu yang digunakan sudah mendukung DST secara bawaan.

4. Malapetaka Tahun Kabisat (Leap Year Bug)

• Kasus: Pada 28 Februari 2010, PlayStation Network (PSN) di seluruh dunia lumpuh. Jutaan konsol PlayStation 3 tiba-tiba tidak dapat terhubung ke internet, tidak bisa memainkan game yang membutuhkan verifikasi online, bahkan beberapa tema dinamis gagal dimuat.
• Masalah: Penyebabnya adalah “ApocalyPS3”. Sistem operasi PS3 salah mengidentifikasi tahun 2010 sebagai tahun kabisat. Ketika jam internal bergulir dari 28 Februari ke 1 Maret, sistem justru mencoba beralih ke tanggal 29 Februari 2010—tanggal yang tidak ada. Kegagalan ini memicu error kritis pada jam internal, yang merambat ke fungsi-fungsi lain yang bergantung pada timestamp yang valid.
• Dampak: Downtime total selama lebih dari 24 jam bagi jutaan pengguna di seluruh dunia. Sony harus bekerja keras untuk merilis perbaikan dan memulihkan kepercayaan pengguna.
• Pencegahan:
  • Buat test case khusus untuk tanggal 29 Februari pada tahun kabisat yang valid (misalnya, 2024, 2028).
  • Uji juga tanggal 29 Februari pada tahun yang bukan kabisat (misalnya, 2100, yang habis dibagi 100 tetapi tidak dengan 400).
  • Pastikan logika perhitungan tahun kabisat sudah benar: (tahun % 4 == 0 && tahun % 100 != 0) || (tahun % 400 == 0).

5. Serangan Detik Kabisat (Leap Second Bug)

• Kasus: Pada 30 Juni 2012, jam atom dunia menambahkan satu detik ekstra untuk sinkronisasi dengan rotasi Bumi. Waktu resmi berjalan dari 23:59:59 ke 23:59:60, lalu ke 00:00:00. Detik ekstra ini meruntuhkan sebagian besar internet.
• Masalah: Banyak sistem, terutama yang berjalan pada kernel Linux saat itu, tidak diprogram untuk menangani menit yang berlangsung selama 61 detik. Ketika Network Time Protocol (NTP) menyiarkan detik 23:59:60, banyak server mengalami kernel panic dan crash. Reddit, LinkedIn, Qantas, dan Gawker Media adalah beberapa korban besar yang mengalami downtime signifikan.
• Dampak: Sebagian besar situs web dan layanan besar lumpuh. Sistem reservasi penerbangan Qantas offline, menyebabkan penundaan besar di seluruh Australia. Kerugian finansial yang ditimbulkan sangat besar.
• Pencegahan:
  • Koordinasi dengan tim infrastruktur untuk melakukan pengujian saat jadwal penambahan leap second diumumkan.
  • Lakukan simulasi sistem dengan waktu 23:59:60 untuk memastikan aplikasi tidak crash.
  • Terapkan teknik smearing, di mana detik ekstra didistribusikan secara bertahap selama beberapa jam sebelum atau sesudah penambahan, alih-alih menambahkannya sekaligus.

6. Kiamat Digital 2038 (Epoch Overflow Bug)

• Kasus: Ini adalah bencana yang belum terjadi, tetapi diprediksi akan berdampak masif pada sistem 32-bit yang lebih tua. Dikenal sebagai bug Y2K38.
• Masalah: Banyak sistem 32-bit mengukur waktu sebagai jumlah detik sejak 1 Januari 1970 (dikenal sebagai Unix epoch time). Nilai ini disimpan dalam integer 32-bit bertanda (signed 32-bit integer). Angka maksimum yang bisa disimpannya adalah 2,147,483,647. Angka ini akan tercapai pada 19 Januari 2038, pukul 03:14:07 UTC. Satu detik setelah itu, integer akan meluap (overflow) dan berubah menjadi angka negatif, yang akan diinterpretasikan sistem sebagai tanggal 13 Desember 1901.
• Dampak Potensial: Sistem perbankan, transportasi, dan perangkat embedded yang masih menggunakan infrastruktur 32-bit bisa mengalami kegagalan total. Transaksi bisa ditolak, data bisa rusak, dan sistem kritis bisa berhenti berfungsi.
• Pencegahan:
  • Migrasikan semua sistem untuk menggunakan tipe data 64-bit untuk menyimpan timestamp.
  • Lakukan audit pada semua library, database, dan kode warisan (legacy code) yang mungkin masih menggunakan time_t 32-bit.
  • Uji aplikasi dengan menyetel jam sistem ke tanggal setelah 19 Januari 2038.

7. Bug Pergantian Kalender (Calendar Rollover Bug)

• Kasus: Pada awal tahun 2022, pemilik mobil Honda dan Acura di seluruh dunia melaporkan bahwa jam di sistem navigasi dan infotainment mereka tiba-tiba mundur 20 tahun ke belakang, ke tahun 2002.
• Masalah: Mirip dengan bug Y2K38, masalah ini disebabkan oleh integer overflow pada cara GPS menghitung waktu. Sistem waktu GPS menggunakan penghitung minggu yang akan di-reset setelah mencapai batas maksimumnya. Dalam kasus ini, nilai penghitung internal sistem Honda meluap dan kembali ke titik awalnya, yang kebetulan disetel pada tahun 2002.
• Dampak: Navigasi menjadi tidak akurat, estimasi waktu kedatangan salah total, dan semua timestamp pada sistem menjadi kacau. Meskipun tidak kritis, bug ini sangat mengganggu dan menurunkan citra teknologi Honda.
• Pencegahan:
  • Lakukan pengujian “end-of-year” dengan menyimulasikan transisi dari 31 Desember pukul 23:59 ke 1 Januari pukul 00:00.
  • Uji pergantian hari, bulan, dan tahun, baik secara manual maupun otomatis, untuk memastikan format dan nilai tanggal tetap konsisten.

8. Kalkulasi Durasi yang Salah

• Kasus: Google Calendar (2018) secara misterius memajukan beberapa acara berulang (recurring events) satu jam lebih awal dari jadwal.
• Masalah: Bug ini dipicu oleh interaksi yang rumit antara acara berulang, zona waktu, dan DST. Saat menghitung jadwal acara berikutnya dalam sebuah seri, logika konversi zona waktu Google salah memperhitungkan transisi DST yang akan datang. Akibatnya, durasi atau waktu mulai acara dihitung salah, menyebabkan acara “melompat” satu jam.
• Dampak: Rapat perusahaan global menjadi kacau. Karyawan di berbagai negara masuk ke panggilan konferensi pada waktu yang salah, menciptakan kebingungan dan membuang-buang waktu.
• Pencegahan:
  • Buat pengujian otomatis yang menghitung durasi atau selisih waktu antara dua tanggal di zona waktu yang berbeda, terutama yang melintasi batas DST.
  • Pastikan logika perhitungan selisih waktu tetap konsisten meskipun zona waktu klien atau server berubah.

9. Ketidakcocokan Waktu Klien-Server

• Kasus: Cloudflare (2014) mengalami pemadaman singkat yang memengaruhi ribuan situs web. Masalahnya bukan pada server mereka, melainkan pada bagaimana mereka memvalidasi sertifikat keamanan SSL.
• Masalah: Sertifikat SSL/TLS memiliki masa berlaku dengan stempel waktu “Not Valid Before” dan “Not Valid After”. Bug pada sistem Cloudflare menyebabkan beberapa servernya memiliki waktu yang sedikit tidak sinkron. Namun, masalah yang lebih besar adalah ketika jam di perangkat pengguna (klien) sangat tidak akurat (misalnya, disetel manual ke tahun lalu). Ketika klien dengan waktu yang salah mencoba mengakses situs, server akan melihat sertifikatnya sebagai “belum valid”, menyebabkan koneksi SSL gagal dan situs tidak dapat diakses.
• Dampak: Ribuan situs web yang menggunakan layanan Cloudflare tidak dapat diakses oleh sebagian pengguna, menciptakan persepsi bahwa situs-situs tersebut sedang down.
• Pencegahan:
  • Pastikan semua server disinkronkan secara ketat menggunakan Network Time Protocol (NTP).
  • Uji aplikasi dengan sengaja mengatur jam perangkat klien maju dan mundur secara ekstrem.
  • Pertimbangkan untuk menambahkan validasi yang memberikan peringatan kepada pengguna jika jam perangkat mereka terlalu jauh dari waktu server.

10. Bug Tanggal Historis

• Kasus: Salah satu kegagalan paling mahal dalam sejarah antariksa, hilangnya Mars Climate Orbiter NASA (1999), sering dikaitkan dengan kesalahan konversi unit metrik. Namun, ada masalah lain yang jarang dibahas: penanganan data navigasi historis.
• Masalah: Perangkat lunak yang melacak data historis dan melakukan perhitungan lintasan jangka panjang harus mampu menangani anomali kalender, seperti transisi dari Kalender Julian ke Gregorian. Transisi ini terjadi pada waktu yang berbeda di negara yang berbeda, dan “menghapus” beberapa hari dari sejarah. Jika perangkat lunak tidak memperhitungkan ini dengan benar saat memproses data navigasi dari stasiun bumi yang berbeda, kesalahan kecil dapat terakumulasi menjadi penyimpangan lintasan yang fatal.
• Dampak: Wahana antariksa senilai $125 juta hancur di atmosfer Mars karena kesalahan perhitungan navigasi yang fatal. Data berharga yang seharusnya dikumpulkan pun hilang selamanya.
• Pencegahan:
  • Jika sistem perlu menangani data historis (misalnya, sebelum tahun 1900 atau bahkan sebelum 1582), uji input tanggal dari era tersebut.
  • Pastikan library waktu yang digunakan mendukung kalender Julian dan dapat menangani konversi ke Gregorian dengan benar.
  • Validasi logika saat menampilkan atau memproses data yang sangat tua.

Pelajaran Berharga

Kasus-kasus di atas membuktikan bahwa pengujian fungsionalitas waktu bukanlah tugas sepele. Ia adalah bagian krusial dari siklus pengembangan.

1. Gunakan Library yang Teruji: Jangan menciptakan logika waktu sendiri. Andalkan library yang matang dan terawat baik seperti Moment.js, date-fns, Luxon (JavaScript), atau Joda-Time/java.time (Java).
2. Uji Semua Skenario Ekstrem: Jangan hanya menguji “hari ini”. Uji secara spesifik:
   • Pergantian tahun (31 Desember ke 1 Januari).
   • Tahun kabisat (28 & 29 Februari).
   • Transisi DST.
   • Tanggal di masa depan yang jauh (mendekati 2038).