Konverter stempel waktu Unix
Ubah stempel waktu Unix menjadi tanggal terbaca di zona waktu mana pun, dan tanggal kembali ke epoch.
Apa itu stempel waktu Unix
Sebuah stempel waktu Unix — disebut juga waktu epoch atau waktu POSIX — adalah satu angka yang menghitung berapa detik telah berlalu sejak 00:00:00 UTC pada 1 Januari 1970, sebuah saat yang dikenal sebagai epoch Unix. Karena ia satu bilangan bulat tanpa zona waktu, tanpa kalender, dan tanpa pemformatan, ia menjadi format yang diraih komputer setiap kali sebuah saat harus disimpan, disortir, dibandingkan, atau dikirim melintasi jaringan. Itulah yang duduk di balik kolom "created_at" dalam basis data Anda, klaim "iat" dan "exp" dalam sebuah JWT, mtime pada sebuah berkas, dan stempel waktu di hampir setiap berkas log yang akan Anda baca.
Imbangannya adalah angka telanjang tak berarti apa pun bagi manusia. 1716197600 adalah sebuah saat yang sangat baik, tetapi Anda tak bisa tahu sekilas apakah itu Selasa lalu atau tiga tahun lalu. Penerjemahan itu, di kedua arah, adalah yang dilakukan alat ini.
Detik atau milidetik — keambiguan yang menjebak
Konvensi Unix asli menghitung detik utuh, dan itulah yang Anda dapatkan dari date +%s dalam sebuah shell, dari time() milik PHP, dan dari time.time() milik Python setelah dipangkas. JavaScript, Java, dan banyak lainnya menghitung milidetik: Date.now() mengembalikan angka seribu kali lebih besar. Keduanya disebut "stempel waktu", dan mencampuradukkannya adalah salah satu bug tanggal paling umum yang ada.
Kegagalannya senyap ketimbang lantang. Baca sebuah nilai milidetik sebagai detik dan tanggal Anda mendarat puluhan ribu tahun di masa depan; baca sebuah nilai detik sebagai milidetik dan semuanya runtuh ke Januari 1970. Tak satu pun melempar galat — Anda cuma mendapatkan tanggal salah yang tampak seperti yang nyata.
Alat ini menebak dari besar angkanya lalu memberi tahu Anda apa yang ditebaknya, tepat di samping hasilnya. Detik epoch hari ini sepuluh digit dan milidetik epoch hari ini tiga belas, jadi tebakannya hampir selalu benar — tetapi "hampir" tak cukup baik untuk sebuah nilai yang akan Anda tempel ke laporan bug, itulah sebabnya pembacaannya selalu terlihat dan selalu sekali klik dari diubah.
Zona waktu, UTC, dan mengapa "lokal" itu licin
Sebuah stempel waktu Unix tak punya zona waktu. Ia mengenali sebuah saat, dan saat yang sama itu secara serentak 09:33 di London, 11:33 di Yerusalem, dan 18:33 di Tokyo. Sebuah zona waktu bukan bagian dari nilainya; ia adalah lensa yang Anda pakai untuk melihat nilai itu.
Itulah sebabnya alat ini menampilkan beberapa lensa sekaligus. UTC adalah rujukan netral yang disepakati setiap server dan log. Waktu lokal Anda adalah yang dilaporkan perangkat Anda sendiri, ditampilkan dengan nama zonanya (seperti Europe/Berlin) sehingga Anda selalu tahu lensa mana yang menghasilkannya — deteksinya terjadi di browser Anda, jadi pengunjung di Berlin melihat waktu Berlin dan pengunjung di Tokyo melihat waktu Tokyo. Baris ketiga adalah zona mana pun yang Anda pilih dari basis data zona waktu IANA yang lengkap, yaitu baris yang Anda inginkan ketika membaca log dari server yang tinggal di tempat lain.
- UTC — rujukan yang disepakati setiap sistem, dan hal yang tepat untuk disimpan dan dicatat.
- Lokal — saat yang sama seperti dilihat perangkat Anda, dilabeli dengan zona yang terdeteksi.
- Sebuah zona pilihan Anda — untuk membaca log dan jejak dari mesin di tempat lain.
- ISO 8601 — format teks pertukaran, mis. 2024-05-20T09:33:20.000Z.
- Relatif — "3 jam lalu", untuk rasa cepat seberapa baru sesuatu.
Offset ditampilkan di samping tiap waktu (+03:00, -04:00) karena mereka tak tetap: kebanyakan zona bergeser sejam untuk waktu musim panas, jadi zona yang sama bisa menghasilkan offset berbeda pada waktu berbeda dalam setahun. Sebuah tanggal dekat transisi adalah persis tempat aritmetika tangan menjadi salah.
Bekerja dengan waktu epoch dalam praktik
Setiap bahasa dan shell punya caranya sendiri untuk menghasilkan dan membaca nilai epoch. Inilah yang layak diingat:
date +%s # shell: current time in seconds date -d @1716197600 # shell (GNU): seconds back to a date Date.now() # JavaScript: current time in MILLIseconds new Date(1716197600 * 1000) # JavaScript: seconds to a Date time.time() # Python: seconds, as a float datetime.fromtimestamp(1716197600, tz=timezone.utc) SELECT EXTRACT(EPOCH FROM now()) -- PostgreSQL: seconds
Sebuah aturan praktis yang menghindari sebagian besar derita tanggal: simpan dan kirim saat sebagai UTC — entah sebuah bilangan bulat epoch atau string ISO 8601 — dan ubah ke zona lokal hanya pada saat terakhir, ketika Anda benar-benar menampilkannya kepada seseorang. Memformat lebih awal adalah cara sebuah bug zona waktu terpanggang ke dalam data Anda alih-alih tetap di lapisan tampilan.
Satu hal lagi yang layak diketahui: sebuah pencacah detik 32-bit bertanda kehabisan pada 19 Januari 2038, "masalah Tahun 2038". Sistem modern memakai nilai 64-bit dan baik-baik saja, tetapi perangkat tersemat lama dan kolom basis data warisan adalah persis tempat Anda mungkin masih menemuinya.
Pertanyaan yang sering diajukan
- Bagaimana ia tahu apakah angka saya detik atau milidetik?
- Dari besarnya: nilai di bawah kira-kira 1e11 dibaca sebagai detik, yang lebih besar sebagai milidetik. Hari ini itu memisahkan dengan bersih detik sepuluh-digit dari milidetik tiga-belas-digit. Pembacaannya ditampilkan di samping hasil dan Anda bisa mengalihkannya dengan satu klik, jadi tebakannya tak pernah disembunyikan dari Anda.
- Zona waktu mana yang dihitung sebagai "lokal"?
- Zona yang dilaporkan perangkat Anda sendiri, dideteksi di browser Anda dan ditampilkan dengan nama agar tak ada keraguan. Itu zona Anda, bukan zona situs — pengunjung di Berlin melihat waktu Berlin dan pengunjung di Tokyo melihat waktu Tokyo.
- Bisakah saya mengubah sebuah tanggal kembali menjadi stempel waktu?
- Ya. Bidang yang sama menerima kedua arah: ketik sebuah angka dan Anda mendapatkan tanggal, ketik sebuah tanggal seperti 2024-05-20 atau 2024-05-20T09:33:20Z dan Anda mendapatkan nilai epoch-nya kembali. Tak ada mode yang perlu dialihkan.
- Apakah ia menangani tanggal sebelum 1970?
- Ya. Stempel waktu sebelum epoch cukup negatif — -86400 adalah 31 Desember 1969 — dan nilai negatif diterima dan dikonversi secara normal.
- Mengapa stempel waktu saya menampilkan tanggal berbeda dari yang saya harapkan?
- Hampir selalu salah satu dari dua alasan: pembacaan detik/milidetik bukan yang Anda asumsikan (periksa labelnya dan alihkan), atau Anda membandingkan sebuah nilai UTC terhadap ekspektasi waktu-lokal. Alat ini menampilkan kedua baris berdampingan sehingga Anda bisa melihat yang mana.
- Apa itu masalah Tahun 2038?
- Sistem yang menyimpan detik epoch dalam bilangan bulat 32-bit bertanda meluap pada 19 Januari 2038 dan membungkus ke angka negatif, memberi tanggal di 1901. Apa pun yang memakai nilai 64-bit — yang hampir semua hal modern — tak terpengaruh, tetapi sistem tersemat warisan dan kolom basis data lama masih bisa berisiko.
- Apakah stempel waktu yang saya masukkan dikirim ke mana pun?
- Tidak. Penguraian, konversi, dan pemformatan semuanya berjalan di browser Anda memakai dukungan tanggal dan zona waktu milik platform sendiri. Tidak ada yang Anda ketik meninggalkan perangkat Anda.