Konverter Unix Timestamp

Konversi timestamp Unix apa pun ke format tanggal dan waktu yang mudah dibaca.

Konverter kami:

• mendeteksi detik (10 digit) dan milidetik (13 digit) secara otomatis
• menampilkan UTC dan waktu lokal
• menampilkan berbagai format termasuk ISO 8601 dan RFC 2822

Konversi tanggal dan waktu apa pun ke timestamp Unix-nya.

Pilih tanggal, tentukan zona waktu Anda, dan dapatkan waktu epoch dalam detik maupun milidetik.

Sangat cocok untuk:

• pengembangan API
• kueri basis data
• mendebug masalah terkait waktu

Waktu Unix adalah sistem untuk melacak suatu titik waktu berdasarkan jumlah detik yang berlalu sejak epoch Unix, yang ditetapkan pada pukul 00:00:00 UTC tanggal 1 Januari 1970. IEEE dan The Open Group mengodifikasikannya dalam standar POSIX (IEEE Std 1003.1), di mana secara resmi dinamakan "Seconds Since the Epoch".

Hal penting yang didokumentasikan oleh POSIX adalah bahwa waktu Unix secara sengaja mengabaikan detik kabisat, sehingga setiap hari dihitung tepat 86.400 detik. Karena nilainya berupa bilangan bulat tunggal yang tidak bergantung pada zona waktu, nilainya tidak membingungkan di berbagai sistem.

Menyimpan waktu sebagai bilangan bulat, seperti yang dicatat oleh MDN Web Docs untuk objek Date di JavaScript, membuat kalkulator waktu untuk operasi aritmatika dan perbandingan menjadi sangat sederhana dibandingkan melakukan parsing string tanggal berformat.

Timestamp Unix 10 digit menghitung detik sejak epoch, sedangkan timestamp 13 digit menghitung milidetik, dan mencampur keduanya adalah kesalahan konversi yang paling sering terjadi.

Menurut MDN Web Docs, Date.now() dan getTime() pada JavaScript mengembalikan nilai milidetik, sehingga 1700000000000 adalah nilai JS yang valid. Sebaliknya, fungsi C POSIX seperti time() dan pemotongan time.time() pada Python, serta sebagian besar basis data SQL dan perintah Bash date +%s, beroperasi dalam detik (1700000000).

Untuk mengonversi di antara keduanya, kalikan detik dengan 1.000 atau bagi milidetik dengan 1.000.

Konverter kami mendeteksi unit secara otomatis berdasarkan jumlah digit, tetapi saat menulis kode Anda harus selalu memastikan unit mana yang diharapkan oleh bahasa atau API Anda agar tidak menghasilkan kalkulator tanggal yang menghasilkan tahun 1970 atau ribuan tahun di masa depan.

Anda dapat menghasilkan timestamp Unix saat ini hanya dengan satu panggilan fungsi di hampir semua bahasa pemrograman.

• Di JavaScript, MDN Web Docs merekomendasikan Math.floor(Date.now() / 1000) untuk detik atau Date.now() untuk milidetik.
• Di Python, time.time() mengembalikan pecahan detik sejak epoch, sesuai dengan fungsi C library time() yang didefinisikan oleh POSIX.
• Pada baris perintah, date +%s milik GNU coreutils mencetak timestamp presisi detik saat ini, sedangkan PHP menggunakan time() dan Go menggunakan time.Now().Unix().
• Mesin SQL menyediakan fungsi seperti UNIX_TIMESTAMP() di MySQL dan EXTRACT(EPOCH FROM now()) di PostgreSQL.

Semua metode ini mengacu pada titik awal 1970 UTC yang sama, sehingga nilainya dapat saling ditukarkan secara langsung setelah Anda menyelaraskan unit detik versus milidetik.

Gunakan timestamp Unix untuk penyimpanan dan aritmatika, serta ISO 8601 untuk pertukaran data yang mudah dibaca manusia dan pencatatan log.

ISO 8601 adalah standar internasional untuk merepresentasikan tanggal dan waktu sebagai string seperti 2023-11-14T22:13:20Z, di mana huruf kapital T memisahkan tanggal dari waktu dan huruf Z di akhir menunjukkan UTC (Zulu time). Huruf-huruf ini sensitif terhadap huruf besar/kecil (case-sensitive), jadi jika Anda merapikan string yang disalin dari sumber huruf campuran, konverter kasus akan membantunya tetap dapat diparse. RFC 3339 dari IETF memprofilkan ISO 8601 untuk penggunaan di Internet dan merupakan standar yang diadopsi oleh sebagian besar API JSON untuk bidang tanggal, karena JSON sendiri (RFC 8259) tidak memiliki tipe data tanggal bawaan.

Bilangan bulat Unix lebih ringkas dan tidak terikat lokasi tetapi tidak mendeskripsikan dirinya sendiri, sementara string ISO 8601 dapat langsung dibaca secara instan. Banyak sistem menyimpan bilangan bulat secara internal dan menserialisasikannya ke ISO 8601 di batas API untuk mendapatkan manfaat dari keduanya.

Sebuah timestamp Unix tidak memiliki zona waktu karena selalu mengacu pada satu momen tunggal yang dihitung dari epoch dalam UTC. Zona waktu hanya penting ketika Anda menampilkan momen tersebut sebagai tanggal jam dinding untuk pengguna.

IANA Time Zone Database (basis data tz) adalah sumber berwenang yang digunakan oleh sistem operasi dan bahasa pemrograman untuk memetakan suatu momen ke waktu lokal, termasuk aturan waktu musim panas dalam sejarah.

Praktik terbaik, yang juga disampaikan oleh MDN Web Docs dan banyak panduan rekayasa perangkat lunak, adalah menyimpan dan mengirimkan timestamp dalam UTC dan hanya mengonversinya ke zona lokal pengguna saat ditampilkan. Ini menghilangkan kebingungan di seputar transisi waktu musim panas dan membuat perbandingan antarwilayah menjadi andal dan konsisten.

Masalah Tahun 2038 (Year 2038 problem) adalah titik waktu ketika integer bertanda 32-bit (signed integer) yang menyimpan waktu Unix mengalami overflow, yang terjadi pada pukul 03:14:07 UTC pada tanggal 19 Januari 2038.

Nilai 32-bit bertanda mencapai batas maksimum pada 2.147.483.647 detik; satu detik setelahnya nilainya akan berputar kembali menjadi angka negatif yang besar, yang oleh kode sederhana akan diartikan sebagai Desember 1901. Masalah ini serupa dengan kekhawatiran historis seputar masalah Tahun 2000 (Y2K), tetapi berakar pada lebar tetap tipe data time_t bahasa C pada sistem generasi lama.

Sistem operasi dan bahasa pemrograman modern sebagian besar telah beralih ke time_t 64-bit, yang menunda terjadinya overflow hingga sekitar 292 miliar tahun ke masa depan. Sistem tertanam (embedded systems) dan format file lawas masih menjadi area risiko utama yang perlu diaudit oleh pengembang.

Unix timestamp merupakan fondasi utama pengelolaan waktu pada sistem backend, log, dan API karena nilainya dapat diurutkan, dihitung selisihnya, dan dibandingkan layaknya bilangan bulat biasa.

Basis data menyimpan kolom created_at dan updated_at sebagai nilai epoch atau tipe data timestamp turunan, sementara lapisan cache memanfaatkan timestamp kedaluwarsa untuk menghapus entri lama. Token keamanan juga mengandalkannya: standar JWT, RFC 7519, mendefinisikan klaim exp (expiration) dan iat (issued-at) sebagai nilai NumericDate, yang secara harfiah merupakan detik sejak Unix epoch.

Log terdistribusi dan event stream memanfaatkan timestamp untuk memastikan urutan peristiwa, dan pembatas laju permintaan (rate limiter) membandingkan epoch saat ini dengan jendela waktu yang tersimpan. Sifatnya yang agnostik terhadap bahasa pemrograman membuatnya ideal untuk mentransfer data waktu antar-layanan.

Unix timestamp negatif merepresentasikan momen sebelum era epoch, sehingga -86400 bertepatan dengan tanggal 31 Desember 1969 pukul 00:00:00 UTC. Definisi POSIX mengizinkan hitungan detik bernilai negatif, dan bahasa seperti JavaScript mendukung hal ini: dokumentasi MDN Web Docs mencatat bahwa objek Date menerima nilai milidetik negatif untuk menyatakan tanggal sebelum 1970.

Fasilitas ini sangat berguna untuk data historis, tanggal lahir, atau pencatatan arsip.

Namun perlu diwaspadai, sejumlah sistem lama, basis data, dan utilitas 32-bit memperlakukan waktu Unix sebagai bilangan tak bertanda (unsigned) atau menolak nilai negatif, yang secara diam-diam memotong nilainya ke waktu epoch atau memunculkan pesan kesalahan. Saat menangani data tanggal historis, pastikan setiap lapisan sistem Anda, mulai dari tipe kolom basis data hingga pustaka klien, mendukung timestamp bertanda.

• Kesalahan yang paling sering dijumpai adalah tertukarnya satuan detik dengan milidetik, yang mengakibatkan hasil tanggal meleset beberapa dekade atau terpaku di tahun 1970. Selalu pastikan satuan yang digunakan sumber data Anda sebelum melakukan konversi, mengingat JavaScript menghasilkan milidetik sementara sebagian besar backend menghasilkan detik.
• Kekeliruan kedua adalah mengasumsikan timestamp memuat informasi zona waktu; kenyataannya tidak, sehingga menerapkan penyesuaian offset lokal sebanyak dua kali akan menghasilkan waktu jam lokal yang keliru.
• Kesalahan lainnya meliputi pengabaian batas Tahun 2038 pada bidang 32-bit, serta anggapan keliru bahwa waktu Unix memperhitungkan detik kabisat (leap seconds), padahal POSIX secara tegas mengecualikannya.
• Terakhir, hindari mengurai format string tanggal secara manual; gunakan pustaka standar dan prioritaskan format ISO 8601 (RFC 3339) untuk pertukaran data sebagaimana disarankan MDN Web Docs, guna menghindari kerancuan format seperti MM/DD versus DD/MM.