Memahami Zona Waktu, UTC, dan Unix Timestamp

Waktu terlihat sederhana sampai Anda mencoba menulis perangkat lunak yang menanganinya dengan benar. Sebuah acara yang dijadwalkan pukul "3 sore" memiliki arti berbeda di Tokyo, London, dan New York. Daylight saving time menggeser jam maju atau mundur — tapi tidak di mana-mana, dan tidak pada tanggal yang sama. Timestamp yang terlihat benar di lingkungan lokal Anda rusak di production karena server berada di zona berbeda.

Zona waktu adalah salah satu topik yang paling andal membingungkan dalam pengembangan perangkat lunak. Artikel ini menjelaskan cara kerjanya, dari mana kompleksitasnya berasal, dan cara menghindari kesalahan paling umum.

Mengapa zona waktu ada

Bumi berotasi 360 derajat dalam 24 jam, yang berarti matahari berada di titik tertinggi pada momen berbeda tergantung garis bujur Anda. Sebelum abad ke-19, setiap kota mengatur jamnya ke waktu matahari lokal — siang hari adalah saat matahari di atas kepala. Ini berfungsi baik sampai kereta api menghubungkan kota-kota yang berjauhan dan jadwal kereta membutuhkan satu jam yang konsisten.

Pada tahun 1884, delegasi dari 25 negara bertemu di Konferensi Meridian Internasional di Washington, D.C. dan sepakat membagi dunia menjadi 24 zona waktu standar, masing-masing diofset dari meridian utama (garis bujur 0 derajat) yang melewati Greenwich, Inggris.

Dalam praktiknya, batas zona waktu mengikuti perbatasan politik, bukan garis bujur yang rapi. China mencakup lima zona geografis tapi menggunakan satu waktu resmi (UTC+8). India menggunakan UTC+5:30 — offset setengah jam. Nepal menggunakan UTC+5:45. Peta zona waktu dunia nyata sangat berantakan.

UTC vs. GMT

GMT (Greenwich Mean Time) adalah waktu matahari rata-rata di Royal Observatory di Greenwich. Ini menjadi referensi waktu dunia selama lebih dari satu abad.

UTC (Coordinated Universal Time) menggantikan GMT sebagai standar internasional pada tahun 1972. UTC didasarkan pada jam atom bukan pengamatan astronomi, membuatnya jauh lebih presisi. Untuk sebagian besar tujuan praktis, UTC dan GMT menunjukkan waktu yang sama, tapi UTC adalah referensi teknis yang benar.

Daylight saving time: kekacauan terorganisir

Sekitar 70 negara menerapkan daylight saving time (DST), menggeser jam maju satu jam di musim semi dan mundur di musim gugur. Tujuannya adalah menyelaraskan jam bangun dengan siang hari. Hasilnya adalah sumber bug dua kali setahun.

Komplikasi utama:

• Tidak universal. Sebagian besar Afrika, Asia, dan Amerika Selatan tidak menerapkan DST. Di dalam AS, Arizona dan Hawaii tidak ikut.
• Tanggal berbeda. EU beralih pada Minggu terakhir Maret dan Oktober. AS beralih pada Minggu kedua Maret dan Minggu pertama November. Mereka tidak sinkron selama beberapa minggu setiap tahun.
• Waktu ambigu. Saat jam mundur, jam dari 1:00 pagi sampai 2:00 pagi terjadi dua kali. Timestamp "1:30 pagi" pada hari itu ambigu.
• Waktu yang dilewati. Saat jam maju, jam dari 2:00 pagi sampai 3:00 pagi tidak ada. Rapat yang dijadwalkan pukul 2:30 pagi pada hari itu tidak pernah terjadi.
• Perubahan politik. Pemerintah bisa (dan memang) mengubah aturan DST dengan sedikit pemberitahuan. Rusia mengadopsi DST permanen pada 2011, lalu beralih ke waktu standar permanen pada 2014. Maroko telah mengubah aturan DST beberapa kali.

ISO 8601: format tanggal universal

Untuk menghindari ambiguitas, standar internasional ISO 8601 mendefinisikan format tanggal dan waktu yang jelas:

2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00

• T memisahkan tanggal dari waktu.
• Z berarti UTC (zona waktu "Zulu" dalam terminologi militer).
• +02:00 atau -05:00 adalah UTC offset.

Format ini tidak ambigu, dapat disortir sebagai teks biasa, dan dipahami secara universal oleh pustaka parsing tanggal. Ketika ragu, gunakan ISO 8601.

Unix timestamp

Unix timestamp (juga disebut epoch time atau POSIX time) adalah jumlah detik yang telah berlalu sejak 1 Januari 1970, 00:00:00 UTC — momen yang dikenal sebagai Unix epoch.

Unix timestamp tidak memiliki zona waktu — mereka selalu dalam UTC. Ini menjadikannya ideal untuk menyimpan dan membandingkan waktu dalam perangkat lunak. Anda mengonversi ke zona waktu lokal hanya di lapisan tampilan.

Database zona waktu IANA

Perangkat lunak tidak hanya membutuhkan UTC offset — ia perlu mengetahui riwayat lengkap dan aturan masa depan untuk setiap wilayah, termasuk transisi DST, perubahan politik, dan anomali historis. Informasi ini tersimpan di Database Zona Waktu IANA (juga disebut database Olson atau tzdata).

Ia menggunakan identifier seperti America/New_York, Europe/Paris, Asia/Tokyo. Setiap entri meng-encode riwayat lengkap UTC offset dan aturan DST untuk lokasi tersebut.

Inilah mengapa Anda tidak boleh menyimpan zona waktu sebagai offset tetap seperti "+02:00". Offset memberitahu Anda perbedaan saat ini dari UTC tapi tidak mengatakan apa-apa tentang aturan DST. Europe/Paris adalah UTC+1 di musim dingin dan UTC+2 di musim panas. Identifier IANA menangkap keduanya.

Bug umum dalam perangkat lunak

1. Menyimpan waktu lokal tanpa zona waktu. Nilai seperti 2026-03-29 14:30:00 tidak bermakna tanpa mengetahui zona waktu mana yang dirujuk. Selalu simpan UTC atau sertakan offset.
2. Berasumsi UTC offset sama dengan zona waktu. UTC+2 di Maret mungkin UTC+3 di Juli (jika wilayah menerapkan DST). Simpan identifier IANA, bukan offset.
3. Mengabaikan transisi DST dalam penjadwalan. Tugas harian pukul 2:30 pagi akan terlewat sekali setahun dan berjalan dua kali sekali setahun jika Anda tidak menangani DST.
4. Berasumsi hari memiliki 24 jam. Pada hari transisi DST, sebuah hari memiliki 23 atau 25 jam. Menghitung "besok pada waktu yang sama" dengan menambahkan 86.400 detik akan meleset satu jam.
5. Menggunakan JavaScript Date secara naif. new Date("2026-03-29") di-parse sebagai UTC di beberapa engine dan sebagai waktu lokal di engine lain. Selalu eksplisit tentang zona waktu.

Praktik terbaik untuk developer

• Simpan waktu dalam UTC. Konversi ke zona waktu lokal pengguna hanya di lapisan presentasi.
• Gunakan identifier zona waktu IANA (America/New_York), bukan offset tetap (-05:00).
• Gunakan ISO 8601 untuk serialisasi. Ia tidak ambigu dan dapat di-parse secara universal.
• Gunakan pustaka tanggal yang matang. Di JavaScript, gunakan Intl.DateTimeFormat atau pustaka seperti date-fns-tz. Di Python, gunakan zoneinfo (3.9+) atau pytz. Di Java, gunakan java.time.ZonedDateTime.
• Perbarui tzdata. Pemerintah mengubah aturan DST. Sistem operasi dan runtime bahasa Anda membutuhkan data zona waktu terkini.
• Uji dengan beberapa zona waktu. Jangan berasumsi server dan pengguna Anda berada di zona yang sama.

Pelajari lebih lanjut

Waktu itu sangat kompleks secara menipu, tapi aturannya terdokumentasi dengan baik dan alatnya sudah matang. Kuncinya adalah menghormati kompleksitas daripada mengasumsikannya tidak ada.

• Ekspresi Cron Didemistifikasi — menjadwalkan tugas lintas zona waktu
• Generator Hash dan Penguji Regex — lebih banyak alat developer di ToolK