Timestamp Unix dijelaskan - epoch, ISO-8601, dan zona waktu

Diterbitkan 19 April 2026

---

Setiap log server, baris basis data, dan respons API di internet mengkodekan "kapan sesuatu terjadi" dalam salah satu dari empat format: Unix epoch (detik atau milidetik), ISO 8601, atau RFC 2822. Jika Anda pernah menempelkan timestamp ke Slack hanya untuk berdebat zona waktu mana yang dipakai, panduan ini untuk Anda. Ini mencakup apa yang sebenarnya dikodekan setiap format, cara mengonversi antar mereka, dan tiga jebakan yang menjebak bahkan pengembang berpengalaman.

Unix epoch: detik sejak 1970-01-01 UTC

Timestamp Unix - juga disebut "waktu epoch" - adalah jumlah detik yang telah berlalu sejak 00:00:00 UTC pada 1 Januari 1970. Titik referensi itu sewenang-wenang tetapi universal; setiap sistem turunan Unix (Linux, macOS, Android, iOS) dan hampir setiap bahasa pemrograman melacak waktu secara internal sebagai hitungan dari momen ini.

Nilai saat ini: 1776495426 diterjemahkan menjadi 2026-04-18 12:17:06 UTC. Tidak ada zona waktu yang dikodekan dalam angka itu sendiri - selalu UTC - yang merupakan kekuatan (tidak ada ambiguitas saat dua sistem membandingkan timestamp) dan jebakan (apa pun yang mengonversi angka menjadi string yang dapat dibaca manusia harus memilih zona waktu, dan biasanya memilih yang lokal).

Detik vs milidetik: sumber kebingungan pertama

JavaScript, Java, dan sebagian besar pustaka standar bahasa modern secara default menggunakan milidetik sejak epoch, bukan detik. Momen yang sama - 2026-04-18 12:17:06 UTC - adalah 1776495426 dalam detik (10 digit) tetapi 1776495426000 dalam milidetik (13 digit). Aturan praktis untuk memeriksa kewarasan timestamp yang Anda terima:

• 10 digit → detik (baris perintah Unix, PHP, Python time.time(), Go).
• 13 digit → milidetik (JavaScript Date.now(), Java System.currentTimeMillis(), sebagian besar API JSON).
• 16 atau 19 digit → mikrodetik atau nanodetik (telemetri khusus dan pengaturan waktu ilmiah).

Nilai detik 10-digit yang ditafsirkan sebagai milidetik dirender sebagai tanggal di tahun 1970 (50+ tahun terlalu awal). Nilai milidetik 13-digit yang ditafsirkan sebagai detik dirender sebagai tanggal ~56.000 M. Kedua kesalahan langsung terlihat begitu timestamp dikonversi - gunakan Convert Milliseconds to Date untuk memeriksa kewarasan, atau Get Current Time in Milliseconds untuk membandingkan dengan sekarang.

ISO 8601: format pertukaran yang mudah dibaca

ISO 8601 adalah format tanggal-waktu yang dapat dibaca manusia yang juga disetujui mesin. Bentuk kanoniknya terlihat seperti: 2026-04-18T12:17:06.520Z. Bagian:

• Tanggal: 2026-04-18 (YYYY-MM-DD, selalu dalam urutan ini).
• Pemisah: T (huruf T literal antara tanggal dan waktu).
• Waktu: 12:17:06.520 (HH:MM:SS.sss, 24 jam).
• Zona waktu: Z untuk UTC, atau offset seperti +07:00 / -05:30 untuk zona lain.

ISO 8601 tidak ambigu (tidak ada kebingungan tanggal regional seperti 04-18 vs 18-04), dapat diurutkan sebagai string biasa (urutan leksikal cocok dengan urutan kronologis ketika zona waktu sama), dan didukung oleh setiap parser modern. Jika Anda mengontrol API yang Anda bangun, lebih utamakan string ISO 8601 daripada angka epoch Unix mentah - mereka membawa zona waktu secara eksplisit, yang menghilangkan seluruh kelas bug.

RFC 2822: format email dan HTTP warisan

RFC 2822 (dan HTTP-date yang hampir identik dari RFC 7231) terlihat seperti Sat, 18 Apr 2026 12:17:06 +0000. Ini adalah format yang akan Anda lihat di header Date: email, header HTTP Last-Modified, dan beberapa API web lama. Dapat dibaca tetapi tidak dapat diurutkan sebagai string biasa (awalan hari minggu memecah urutan leksikal), jadi sistem semakin sering mengembalikan ISO 8601 di samping atau menggantikan RFC 2822. Saat Anda perlu menghasilkan RFC 2822 secara manual, gunakan pustaka daripada membangun string sendiri - nama hari dan singkatan bulan sensitif terhadap locale dan mudah salah.

UTC vs waktu lokal: akar dari sebagian besar bug timestamp

Timestamp Unix epoch selalu UTC; string ISO 8601 dapat berupa UTC (Z) atau offset apa pun; RFC 2822 hampir selalu membawa offset. Tetapi ketika program menampilkan timestamp, biasanya dikonversi ke zona waktu lokal mesin yang menampilkan.

Ini baik-baik saja untuk satu pengguna tetapi menyebabkan kekacauan dalam tiga skenario:

• Berbagi timestamp di chat. "Deploy terjadi pada 14:00" ambigu - 14:00 milik siapa? Tempel nilai ISO 8601 (2026-04-18T14:00:00+07:00) atau sebutkan zona waktu secara eksplisit.
• Log dari beberapa server. Atur setiap server ke UTC. Selalu. Agregator log dan perkakas respons insiden mengasumsikan UTC; mencampur zona waktu di log adalah cara tercepat untuk salah mengaitkan rantai sebab-akibat.
• Jadwal yang menghadap pengguna. Simpan waktu acara dalam UTC (atau zona waktu sumber acara dengan offset eksplisit) dan konversi pada waktu tampilan. Jangan simpan "7pm" tanpa zona waktu; "7pm" dalam sesi satu pengguna mungkin 4pm untuk pengguna lain.

Tiga jebakan umum (dan cara menangkapnya)

1. Timestamp integer-vs-string di JSON. JSON.parse JavaScript akan dengan setia menghasilkan angka untuk 1776495426520 - tetapi jika API mengembalikan timestamp yang sama sebagai string "1776495426520", kode hilir yang melakukan aritmatika padanya akan mengkoersinya secara diam-diam. Selalu periksa tipe sebelum meneruskan ke new Date().

2. Bulan 0-11 di JavaScript Date. new Date(2026, 3, 18) adalah 18 April 2026, bukan 18 Maret 2026. Bulan diindeks 0 tetapi hari dan tahun diindeks 1. Lebih utamakan konstruktor ISO 8601 (new Date("2026-04-18")) yang mengikuti penomoran alami.

3. Transisi DST. Pada malam "maju jam", 2:30 pagi waktu lokal tidak ada; pada malam "mundur jam", 1:30 pagi terjadi dua kali. Jika sistem Anda menyimpan string waktu lokal, momen ini menciptakan timestamp yang mustahil atau ganda. Penyimpanan UTC menghilangkan masalah; pustaka Date seperti Luxon atau date-fns-tz menangani konversi secara eksplisit.

Alat terkait

• Convert Milliseconds to Date - tempelkan timestamp, dapatkan tanggal terformat UTC dan lokal.
• Get Current Time in Milliseconds - pembacaan epoch langsung yang diperbarui setiap detik.
• MD5 Converter - hash string untuk checksum atau kunci deduplikasi.
• JSON Parser - periksa respons API yang berisi bidang timestamp.

← Kembali ke Utility Tools