Konverter Unix Timestamp

detik epoch = jumlah hari sejak 1 Januari 1970 dikali 86.400 ditambah detik sejak tengah malam UTC; tanggal UTC, waktu UTC, dan hari UTC adalah aritmetika yang sama yang dijalankan terbalik, dan ISO 8601 adalah bentuk tertulisnya; milidetik epoch = detik epoch × 1.000; arah dan satuan hanya menentukan masukan mana yang dibaca, sedangkan stempel waktu serta tanggal dan waktu dipakai menurut arah itu

arah

Mau ke arah mana: stempel waktu dimasukkan lalu tanggal yang keluar, atau tanggal dan waktu dimasukkan lalu stempel waktu yang keluar

stempel waktu

Hitungannya sendiri, dalam detik atau milidetik bergantung pada kolom satuannya. Hanya dipakai pada arah stempel waktu ke tanggal

satuan

Apakah angka yang Anda masukkan menghitung detik (10 digit untuk tanggal di abad ini) atau milidetik (13 digit). Hanya dipakai pada arah stempel waktu ke tanggal

tanggal

Hari kalender dalam UTC, ditulis sebagai YYYY-MM-DD. Hanya dipakai pada arah tanggal ke stempel waktu

waktu

Jam dinding dalam UTC, dalam bentuk HH:MM atau HH:MM:SS. Hanya dipakai pada arah tanggal ke stempel waktu

tanggal UTC

Tanggal kalender tempat stempel waktunya jatuh, dalam UTC. Inilah hasil utamanya

waktu UTC

Jam dalam UTC, selalu dengan detik. Pecahan detik di masukannya dibuang, bukan dibulatkan

hari UTC

Hari dalam seminggu saat tanggal itu jatuh, dicetak panjang sebagai Kamis — sebuah nama, bukan angka

ISO 8601

Bentuk ISO 8601 yang lengkap, misalnya 15 Januari 2026 pukul 12:00 UTC menjadi 2026-01-15T12:00:00Z, siap disalin ke kode atau ke log

detik epoch

Saat yang sama sebagai detik bulat sejak 1970-01-01T00:00:00Z, dipotong dan bukan dibulatkan supaya tidak pernah berselisih dengan jam di atasnya

milidetik epoch

Saat yang sama dalam milidetik — nilai detiknya dikalikan 1.000, dan bagian di bawah satu detik yang dibawa masukannya tetap disimpan

Pakai halaman ini ketika sebuah angka dan sebuah tanggal harus dipasangkan: membaca stempel waktu dari log peladen, dari balasan API, atau dari baris basis data; memeriksa apakah nilai yang dikirim kepada Anda dalam detik atau milidetik; atau membuat stempel waktu untuk disimpan. Halaman ini sengaja berhenti di UTC. Ia tidak mengubah ke waktu lokal Anda dan tidak menanyakan Anda ada di zona mana — stempel waktu Unix tidak punya zona, jadi jawaban yang jujur adalah jawaban UTC, dan mengubahnya menjadi bacaan jam lokal adalah tugas kalkulator zona waktu. Halaman ini juga tidak melakukan aritmetika atas stempel waktu: untuk "berapa nilai ini ditambah tiga puluh hari", ubah dulu lalu pakai kalkulator tanggal.

1. 1.768.478.400 — saat rujukannya

   1. Angkanya dalam detik, jadi ia sudah merupakan nilai epoch — tidak ada pengubahan yang diperlukan sebelum membacanya
   2. Membaginya dengan 86.400 memberi jumlah hari bulat sejak 1 Januari 1970, dan sisanya adalah waktu dalam hari itu: hasilnya mendarat pada 15 Januari 2026 pukul 12:00:00 UTC
   3. 15 Januari 2026 jatuh pada Kamis, dan itulah yang dicetak baris hari dalam seminggu: Kamis, ditulis panjang, bukan angka 4
   4. Ditulis lengkap, tanggal 15 Januari 2026 pukul 12:00:00 UTC menjadi 2026-01-15T12:00:00Z, bentuk yang diharapkan log atau API
   5. Baris milidetiknya adalah saat yang sama dikalikan 1.000, dan itulah bentuk nilai yang sama ketika sebuah sistem melaporkannya dalam milidetik

   Inilah nilai yang halaman ini buka pertama kali, dan ia layak dihafal sebagai jangkar: 1.768.478.400 adalah tengah hari UTC pada 15 Januari 2026. Setiap pengubahan lain di halaman ini lebih mudah diperiksa begitu satu stempel waktu sudah akrab, karena jawaban yang salah biasanya salah sebanyak hari bulat atau sebanyak faktor 1.000, dan keduanya langsung terlihat terhadap jangkar yang Anda kenal.

2. 2.147.483.647 — detik terakhir era 32 bit

   1. 2.147.483.647 adalah 2 pangkat 31 dikurangi 1: angka terbesar yang bisa ditampung bilangan bulat bertanda 32 bit
   2. Dibaca sebagai hitungan epoch, ia adalah 19 Januari 2038 pukul 03:14:07 UTC, dan itulah inti masalah tahun 2038 — sistem yang menyimpan stempel waktunya dalam tipe itu kehabisan ruang satu detik kemudian lalu berbalik ke tanggal di tahun 1901
   3. 19 Januari 2038 jatuh pada Selasa, dan baris hari dalam seminggu mencetak Selasa; angka 2 adalah nilai internal baris itu, bukan yang ditampilkannya
   4. Baris detiknya mengembalikan angkanya tanpa berubah, dan itulah pemeriksaannya bahwa nilainya masuk dan keluar melalui aritmetika yang sama

   Ini baris dari tabel rujukan di bawah, dijalankan melalui kalkulatornya. Masalah tahun 2038 bukanlah tanggalnya tidak terjangkau — halaman ini menanganinya tanpa keluhan — melainkan bahwa program yang memakai penghitung bertanda 32 bit tidak bisa mewakili detik berikutnya. Penghitung 64 bit tidak punya batas semacam itu dalam horizon yang berarti, dan itulah sebabnya nilai yang sama dalam milidetik adalah 2.147.483.647.000.

3. Nilai milidetik dengan pecahan: 1.768.478.400.500

   1. Angkanya punya 13 digit dan satuannya menyebut milidetik, jadi ia adalah saat yang sama dengan contoh pertama ditambah setengah detik
   2. Jamnya membuang pecahannya alih-alih membulatkannya, jadi ia terbaca 12:00:00 dan bukan 12:00:01
   3. Baris detiknya dipotong agar cocok: 1.768.478.400, bukan 1.768.478.401
   4. Baris milidetiknya menyimpan pecahannya, karena hanya di situ pecahan itu ada di dalam hasilnya

   Inilah satu-satunya kasus ketika pembulatan dan pemotongan tidak sepakat, dan alasan baris detiknya memotong. Membulatkan setengah detik ke atas akan mencetak nilai detik yang satu lebih besar daripada jam tepat di atasnya, dan pembaca yang membandingkan kedua baris itu akan menyimpulkan salah satunya rusak. Menjaga setiap baris konsisten dengan waktu yang ditampilkan lebih penting daripada menjaga bilangan bulat yang terdekat.

4. Arah sebaliknya: 15 Januari 2026, pukul 12:00:30 UTC

   1. Tanggalnya diubah menjadi hitungan hari sejak 1 Januari 1970 lalu dikalikan 86.400 untuk mendapat detik sampai tengah malam
   2. Tiga puluh detik setelah tengah malam ditambahkan: jumlahnya 1.768.478.430, yaitu nilai contoh pertama ditambah 30
   3. Kolom waktunya menerima detik, jadi 12:00:30 dibaca tepat dan bukan dibulatkan turun ke menitnya
   4. Baris tanggal dan harinya kembali tanpa berubah, karena mengubah keluar lalu masuk lagi adalah operasi identitas

   Menjalankan arah sebaliknya atas nilai yang sudah Anda ubah adalah cara termurah untuk memeriksa sebuah stempel waktu: kalau perjalanan bolak-baliknya tidak kembali ke angka yang Anda mulai, kemungkinan besar satuannya salah. Mengisi angka 10 digit sementara satuannya menyebut milidetik meleset sebanyak faktor seribu, dan itu muncul di sini sebagai tanggal di Januari 1970 alih-alih sebagai kesalahan.

Semua yang dilaporkan halaman ini dalam UTC, dan ia tidak pernah mengubah ke zona waktu lokal — stempel waktu Unix didefinisikan tanpa zona, jadi halaman yang mengubahnya menjadi bacaan jam lokal adalah kalkulator zona waktu. Jendelanya adalah 1 Januari 1970 pukul 00:00:00 UTC sampai 31 Desember 2100 pukul 23:59:59 UTC, dan nilai di luarnya ditolak alih-alih dihitung diam-diam: stempel waktu negatif adalah stempel waktu Unix yang sah untuk tanggal sebelum epoch, tetapi halaman ini mengatakannya lalu berhenti daripada mengembalikan jawaban tahun 1969 yang bertentangan dengan rentangnya sendiri. Pecahan detik dipotong, bukan dibulatkan, jadi nilai milidetiknya tidak kehilangan ketelitian tetapi juga tidak memengaruhi detik yang ditampilkan. Halaman ini tidak mengurai teks tanggal dalam format lain, tidak membaca stempel waktu mesin yang Anda pakai, dan tidak melakukan aritmetika — untuk tanggal tiga puluh hari setelah sebuah nilai hasil pengubahan, pakailah kalkulator tanggal. Dua baris teks — Waktu (UTC) dan ISO 8601 — keluar persis seperti sebuah sistem menuliskannya, 12:00:00 dan 2026-01-15T12:00:00Z: tidak ada pemisah atau terjemahan yang perlu diterapkan padanya. Dua baris hitungan, sebaliknya, adalah angka dan mengikuti penulisan angka Indonesia, seperti pada 1.768.478.400 dan 1.768.478.400.000.

Apa itu waktu epoch?

Waktu epoch adalah jumlah detik yang sudah berjalan sejak 1970-01-01T00:00:00 UTC, dan itulah titik nol tempat sistem Unix menghitung. Ia juga disebut unix time atau POSIX time. Tidak ada apa pun tentangnya yang bergantung pada tempat Anda berada: waktu epoch didefinisikan dalam UTC, jadi saat yang sama punya nilai yang sama di seluruh dunia, dan dua mesin di zona berbeda yang berselisih soal jam lokal tetap sepakat soal stempel waktunya.

Bagaimana cara mengonversi timestamp ke tanggal?

Masukkan nilainya, sebutkan apakah ia menghitung detik atau milidetik, lalu baca tanggal dan waktu yang keluar. Satu hal yang perlu diperiksa lebih dulu adalah jumlah digitnya: hitungan detik untuk tanggal di abad ini punya 10 digit dan hitungan milidetik punya 13. Nilai 13 digit yang dibaca sebagai detik mendarat puluhan ribu tahun di masa depan dan ditolak; nilai 10 digit yang dibaca sebagai milidetik mendarat di Januari 1970, dan itulah kesalahan yang tidak mengumumkan dirinya sendiri. Mengubahnya kembali lewat arah yang lain adalah konfirmasi tercepat.

Apa itu masalah tahun 2038?

Masalah tahun 2038 adalah apa yang terjadi ketika sebuah sistem menyimpan stempel waktu dalam bilangan bulat bertanda 32 bit: nilai terbesar yang bisa ditampung tipe itu adalah 2.147.483.647, yaitu 19 Januari 2038 pukul 03:14:07 UTC (2038-01-19T03:14:07Z), dan satu detik kemudian penghitungnya meluap ke tanggal di tahun 1901. Ia batas penyimpanan dan bukan batas stempel waktunya sendiri, dan penghitung 64 bit tidak mengalaminya. Halaman ini mengubah nilai itu dan nilai-nilai sesudahnya tanpa kesulitan, karena ia bekerja dengan presisi ganda dan bukan dengan bilangan bulat 32 bit.

Sebaiknya menyimpan detik atau milidetik?

Keduanya dipakai luas dan tidak ada yang salah, tetapi sebuah nilai tidak bisa mengatakan sendiri yang mana ia, jadi satuannya harus ikut bersama angkanya atau disepakati lebih dulu. Milidetik menyimpan pecahan detik dan itulah yang dipakai objek Date di JavaScript serta banyak sistem pencatatan log; detik adalah yang didefinisikan POSIX dan yang dikembalikan sebagian besar API dan basis data. Konversi antara keduanya adalah perkalian dengan 1.000, dan halaman ini mencetak kedua barisnya supaya pasangannya terlihat sekilas.

Apakah format ISO 8601 sama dengan stempel waktu?

Tidak, dan keduanya mudah tertukar karena sama-sama menjelaskan saat yang sama. ISO 8601 adalah bentuk tertulisnya — 15 Januari 2026 pukul 12:00 UTC ditulis 2026-01-15T12:00:00Z — dan ia bisa dibaca manusia, bisa diurutkan, dan tidak ambigu soal selisih UTC-nya berkat huruf Z di ujungnya. Stempel waktu Unix adalah satu hitungan tanpa bentuk penulisan sama sekali. Teks ISO 8601 itulah yang Anda tempel ke dokumen atau URL; hitungannya itulah yang Anda simpan atau bandingkan. Halaman ini mencetak keduanya dari pengubahan yang sama, jadi keduanya bisa diperiksa satu terhadap yang lain.

• The Open Group Base Specifications — Seconds Since the Epoch — The Open Group — the normative definition of the epoch and of leap-second handling
• RFC 3339 — Date and Time on the Internet: Timestamps — IETF — the format of the Z-suffixed string this page prints
• MDN — Date — MDN Web Docs — the millisecond count and its range in JavaScript