Kenapa Aplikasi Buatan AI-mu Menampilkan Waktu yang Salah (dan Cara Memperbaiki Zona Waktu)
Aplikasi menampilkan waktu yang salah saat ia menyimpan bacaan jam alih-alih sebuah momen, menampilkan zona waktu server alih-alih zona waktu pengguna, atau mengabaikan pergeseran waktu musim panas — penyebab tersembunyi di balik janji temu yang dobel-booking dan pengingat jam 2 pagi.
Kenapa Aplikasi Buatan AI Menampilkan Waktu yang Salah?
Karena dua orang di tempat berbeda bisa sama-sama melihat waktu yang benar, tapi menampilkan dua angka yang berbeda — ketidakcocokan itulah inti dari seluruh masalah zona waktu. Seorang pelanggan di Madrid memesan slot jam 3 sore-mu; kamu di Mexico City, dan layarmu menampilkan booking yang sama di jam 8 pagi. Kamu menatapnya, yakin ada yang rusak.
Tidak ada yang rusak. Sekarang jam 3 sore di Madrid dan jam 8 pagi di Mexico City, di saat yang benar-benar sama. Kalian berdua benar. Celah itu — di mana dua orang yang sama-sama benar melihat dua angka yang berbeda — ada di balik sejumlah besar laporan bug “aplikasiku bertingkah aneh”.
Ini menyelinap masuk karena selama proses membangun dan menguji, kamu adalah satu-satunya orang, di satu tempat, di satu perangkat. Semuanya cocok. Zona waktu baru menunjukkan taringnya ketika orang kedua, di tempat lain, melihat waktu yang sama. Kalau aplikasimu punya pengguna di lebih dari satu kota — atau mengirim pesan terjadwal jenis apa pun — ini akan mengejarmu cepat atau lambat. Lebih baik menghadapinya dengan sengaja.
Sebenarnya, Apa Itu Zona Waktu?
Zona waktu adalah setengah bagian “tempat” dari sebuah waktu — bagian yang mengubah satu momen universal menjadi bacaan jam lokal. Ini satu gagasan yang membuat sisanya jadi masuk akal: setiap waktu punya dua bagian.
- Momennya — satu instan tunggal yang sama di mana pun di Bumi.
- Tempatnya — di mana kamu berada saat membaca jam.
“Jam 3 sore” saja tidak berarti apa-apa. Jam 3 sore di mana? Komputer menangani ini dengan menyimpan momen dalam format netral, tanpa tempat (kamu akan dengar builder-mu menyebut “UTC” — anggap saja sebagai jam di titik referensi tetap), lalu menampilkannya dalam waktu lokal masing-masing orang saat mereka melihatnya.
Ketika sebuah aplikasi menampilkan waktu yang salah, hampir selalu karena ia kehilangan jejak salah satu dari dua bagian itu — ia lupa tempatnya, atau memang tidak pernah menyimpan momen yang sesungguhnya sejak awal.
Apa Penyebab Bug Zona Waktu di Aplikasi?
Tiga kesalahan spesifik menyebabkan hampir semua bug zona waktu: menyimpan bacaan jam alih-alih momen sesungguhnya, menampilkan zona waktu server alih-alih zona waktu pengguna, dan mengabaikan pergeseran waktu musim panas.
1. Aplikasi menyimpan bacaan jam, bukan momen. Seseorang memilih “jam 9 pagi” dan aplikasi menyimpan teks “jam 9 pagi” tanpa tempat yang menyertainya. Sekarang ia menampilkan “jam 9 pagi” ke semua orang, di mana pun, yang kadang memang itu yang kamu mau (pengingat minum obat yang seharusnya berbunyi jam 9 pagi lokal untuk masing-masing orang) dan kadang jadi bencana (webinar langsung yang seharusnya dimulai pada satu momen tunggal untuk semua orang). Kalau aplikasi salah menebak mana yang kamu maksud, waktunya jadi melenceng.
2. Aplikasi menampilkan waktu server, bukan waktu pengguna. Aplikasimu berjalan di komputer dalam sebuah data center — katakanlah, di Virginia. Kalau tidak ada yang memberitahunya sebaliknya, ia dengan senang hati akan menampilkan waktu Virginia ke semua orang. Penggunamu di London jadi selisih satu sore penuh dan tidak tahu kenapa.
3. Waktu musim panas menggeser jam dan aplikasimu tidak menyadarinya. Dua kali setahun, banyak tempat menggeser jam mereka satu jam. Rapat rutin “setiap Selasa jam 9 pagi” yang kamu atur di musim dingin tiba-tiba jadi jam 8 atau jam 10 di musim panas kalau aplikasinya terkunci pada selisih waktu tetap alih-alih pada sebuah tempat.
Tiga Versi Nyata dari Masalah Ini
Acara yang dimulai tiga kali. Seorang founder membuat halaman sederhana untuk workshop online dengan satu waktu mulai tercantum di sana: “Dimulai jam 6 sore.” Peserta di tiga negara masing-masing membaca “jam 6 sore” sebagai jam 6 sore waktu lokal mereka sendiri. Sepertiga dari mereka bergabung satu jam telat, beberapa bergabung satu jam lebih awal, dan semua orang menyalahkan link-nya. Perbaikannya bukan link yang lebih baik — melainkan menampilkan ke masing-masing orang waktu mulai versi lokal mereka sendiri, dengan zonanya dieja jelas.
Newsletter yang tiba jam 2 pagi. Email “kirim setiap pagi jam 8” dikirim jam 8 pagi waktu server. Untuk separuh daftar pelanggan di Eropa, itu tengah malam buta. Tingkat buka email untuk pelanggan-pelanggan itu sangat buruk, dan kelihatannya seperti masalah konten. Padahal itu masalah zona waktu.
Minggu yang dobel-booking. Sebuah aplikasi booking membiarkan dua orang memesan slot pijat yang sama pada malam ketika jam “mundur satu jam”, karena jam 1:30 pagi terjadi dua kali malam itu dan aplikasi memperlakukan keduanya sebagai momen yang sama. Jarang terjadi, tapi ini jenis bug yang bisa membuatmu kehilangan pelanggan sungguhan dan harus minta maaf sungguhan.
Apa yang Harus Kamu Minta dari Builder-mu untuk Memperbaiki Zona Waktu?
Minta empat hal spesifik ini, dengan bahasa sederhana — kamu tidak perlu mempelajari semua ini secara rinci. Salin saja ini:
“Simpan setiap waktu sebagai momen UTC, dan simpan juga zona waktu masing-masing pengguna.”
“Saat menampilkan sebuah waktu, tampilkan dalam zona waktu si penonton, dan tulis zonanya tepat di sebelahnya — seperti
3:00 PM (waktumu)atau3:00 PM CST.”
“Untuk apa pun yang berulang — pengingat, jadwal, acara rutin — jangkarkan pada sebuah tempat (seperti ‘America/Mexico_City’), bukan pada angka jam yang tetap, supaya waktu musim panas ditangani secara otomatis.”
“Biarkan aku mengetesnya seolah-olah aku berada di negara lain.”
Yang terakhir itu lebih penting dari kedengarannya, dan ini yang membawa kita ke bagian yang bisa kamu lakukan sendiri.
Bagaimana Cara Menguji Aplikasimu untuk Bug Zona Waktu?
Kamu bisa menangkap sebagian besar bug zona waktu dalam dua menit tanpa perlu pengguna di negara lain — cukup berpura-pura berada di sana:
- Buka pengaturan tanggal-dan-waktu di ponsel atau komputermu dan ganti zona waktunya ke suatu tempat yang jauh — Tokyo, London, di mana saja.
- Muat ulang aplikasimu.
- Perhatikan setiap tempat di mana waktu muncul. Apakah masih masuk akal? Apakah ia memberitahumu waktu milik siapa itu?
Kalau sebuah booking yang seharusnya jam 3 sore sekarang terbaca jam 4 pagi tanpa penjelasan, kamu menemukan bug sebelum pelanggan menemukannya. Kembalikan pengaturanmu setelah selesai. Untuk kasus pengingat berulang dan waktu musim panas, cara paling pasti untuk mengeceknya adalah minta satu teman di negara lain untuk melihat satu tanggal dan memberitahumu jam berapa yang ia lihat.
Apakah Kamu Perlu Mengkhawatirkan Zona Waktu Sama Sekali?
Sejujurnya — kadang tidak, dan ini patut dikatakan. Kalau setiap orang yang menggunakan aplikasimu berada di kota yang sama — alat penjadwalan staf sebuah restoran lokal, pendaftaran anggota klub lingkungan — kamu bisa hampir sepenuhnya melewati bagian-bagian sulitnya. Cukup konsisten dan beri label pada waktunya supaya tidak ada keraguan.
Zona waktu menjadi perhatian sungguhan begitu salah satu dari dua hal ini benar: dua orang di tempat berbeda berbagi satu waktu, atau aplikasimu mengirim sesuatu sesuai jadwal. Begitu kamu melewati batas itu, asuransi termurah juga yang paling sederhana: selalu tampilkan zona waktu di sebelah waktunya. Kebiasaan itu saja menghilangkan ambiguitas yang menyebabkan sebagian besar cerita di atas, bahkan sebelum perbaikan yang lebih mendalam diterapkan.
Jadi lain kali kamu menambahkan kolom tanggal atau waktu ke aplikasimu, tanyakan satu pertanyaan ini pada dirimu sendiri sebelum melanjutkan: ini waktu milik siapa? Kalau kamu bisa menjawabnya dengan lantang, kamu sudah selangkah lebih maju dibanding kebanyakan aplikasi yang dibuat orang.