Konverter stempel waktu Unix

Apa itu stempel waktu Unix

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, 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 saat harus disimpan, diurutkan, dibandingkan, atau dikirim melintasi jaringan. Itulah yang duduk di balik kolom "created_at" dalam basis data Anda, klaim "iat" dan "exp" dalam JWT, mtime pada berkas, dan stempel waktu di hampir setiap berkas log yang akan Anda baca.

Imbangannya adalah bahwa angka telanjang tak berarti apa pun bagi manusia. 1716197600 adalah 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 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 nilai milidetik sebagai detik dan tanggal Anda mendarat puluhan ribu tahun di masa depan; baca nilai detik sebagai milidetik dan semuanya runtuh ke Januari 1970. Tak satu pun melempar galat — Anda hanya 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 nilai yang akan Anda tempel ke laporan bug, itulah sebabnya pembacaannya selalu terlihat dan selalu hanya sekali klik untuk dialihkan.

Zona waktu, UTC, dan mengapa "lokal" itu licin

Stempel waktu Unix tak punya zona waktu. Ia menandai satu saat: 1716197600 adalah 2024-05-20T09:33:20Z, dan saat yang sama itu secara serentak 10:33 di London, 12:33 di Yerusalem, dan 18:33 di Tokyo, karena hari itu London dan Yerusalem memakai waktu musim panas sedangkan Jepang tidak memakainya sama sekali. 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 peramban 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.
• 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 gambaran 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. Tanggal dekat transisi adalah persis tempat aritmetika manual 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

Aturan praktis yang menghindari sebagian besar derita soal tanggal: simpan dan kirim saat sebagai UTC — entah 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 bug zona waktu tertanam ke dalam data Anda alih-alih tetap di lapisan tampilan.

Satu hal lagi yang layak diketahui: pencacah detik 32-bit bertanda habis 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.

Apa itu epoch, dan mengapa tidak setiap stempel waktu dimulai dari 1970

Epoch dalam arti ini hanyalah nol yang dipilih — saat yang ditetapkan sebagai titik mulai pencacah. Epoch Unix adalah 00:00:00 UTC pada 1 Januari 1970, dan ia dipilih karena tanggal itu bulat dan mudah, bukan karena diturunkan dari apa pun: tak ada apa pun dalam format itu sendiri yang mengharuskan hari itu. Unix awal menghitung seperenam puluh detik dari nol yang jauh lebih dekat, dan manual edisi ketiga menyatakan terus terang mengapa itu tak akan bertahan: tiga puluh dua bit seperenam puluhan menjamin krisis setiap 2,26 tahun, yaitu kira-kira setiap 828 hari. Detik utuh dalam tiga puluh dua bit yang sama mencapai seratus tiga puluh enam tahun, atau enam puluh delapan bila pencacahnya bertanda — itulah tanggal 2038 di atas.

Riwayat itulah alasan memeriksa angka panjang sebelum memercayainya. Sistem lain menghitung dari nol lain dengan resolusi lain, dan membaca salah satunya sebagai detik Unix tidak membuat Anda meleset beberapa jam — melainkan berabad-abad. Inilah yang paling mungkin Anda temui:

• Windows FILETIME — tik seratus nanodetik sejak 1 Januari 1601 UTC. Bagi dengan sepuluh juta dan kurangi 11644473600 untuk mendapat detik Unix; saat 1716197600 yang dipakai di sepanjang panduan ini adalah 133606712000000000 dalam skema itu.
• .NET DateTime.Ticks — tik seratus nanodetik yang sama, tetapi dihitung dari awal tahun 1. Epoch Unix sendiri berada di 621355968000000000 tik, dan itulah angka yang dikurangkan sebelum membagi.
• Tanggal rujukan Apple — detik sejak 1 Januari 2001 UTC, dipakai Cocoa dan Core Data. Tambahkan 978307200 untuk mendapat detik Unix: 1716197600 di sana adalah 737890400.
• Nomor seri Excel — hari, bukan detik, dan dihitung dari 30 Desember 1899, karena Excel memperlakukan 1900 sebagai tahun kabisat padahal bukan.
• Waktu GPS — detik sejak 6 Januari 1980, dihitung tanpa pernah melewatkan detik kabisat, sehingga waktu GPS dan UTC tidak lagi sepakat.

Yang terakhir menunjuk pada sesuatu yang benar tentang nilai Unix itu sendiri: ia bukan bacaan stopwatch. POSIX mendefinisikannya sebagai nilai yang menghampiri jumlah detik yang berlalu sejak epoch, dan mensyaratkan setiap hari dihitung tepat 86400 detik — jadi detik kabisat yang disisipkan ke UTC sama sekali tidak dihitung. Selisih dua stempel waktu Unix karena itu adalah jumlah detik kalender di antaranya, bukan jumlah detik yang sungguh berlalu, dan nilai itu paling baik dipahami sebagai penyandian bacaan kalender UTC. Itu pula sebabnya tidak ada stempel waktu yang pernah menyebut detik kabisat: penyandian ini tidak punya tempat untuknya.

Dari tanggal ke nilai epoch: shell, JavaScript, dan Python

Blok di atas mengubah nilai epoch menjadi sesuatu yang terbaca. Arah sebaliknya — tanggal yang sudah Anda punya, sebagai teks atau sebagai kumpulan angka, diubah menjadi nilai epoch — adalah tempat bug zona waktu bermukim, karena masing-masing dari ini diam-diam mengandaikan zona ketika teksnya tidak menyebut satu pun. Inilah pekerjaan yang sama dengan tiga cara, pada saat 2024-05-20T09:33:20Z dari panduan ini. Baris shell memakai date milik GNU; date pada BSD dan macOS menerima opsi lain.

date -u -d '2024-05-20 09:33:20' +%s     # 1716197600 — -u reads the text as UTC
date -d '2024-05-20 09:33:20 UTC' +%s    # the same, with the zone named in the text
date -d '2024-05-20 09:33:20' +%s        # neither: your machine's zone, another instant

Date.parse('2024-05-20T09:33:20Z') / 1000    // 1716197600 — the Z is what makes it UTC
new Date('2024-05-20T09:33:20Z').getTime()   // the same instant in milliseconds
Date.parse('2024-05-20 09:33:20')            // no Z: your machine's zone, another instant

from datetime import datetime, timezone
int(datetime(2024, 5, 20, 9, 33, 20, tzinfo=timezone.utc).timestamp())   # 1716197600 — an aware datetime
int(datetime.fromisoformat('2024-05-20T09:33:20+00:00').timestamp())     # the same, parsed from a string
int(datetime(2024, 5, 20, 9, 33, 20).timestamp())                        # naive: your machine's zone

Polanya sama di ketiganya: sebutkan zonanya, atau Anda mewarisi zona yang disetel pada mesin. Angka yang benar di laptop Anda dan meleset berjam-jam di laptop kolega hampir selalu ini, dan itulah sebabnya alat di atas menampilkan UTC dan bacaan lokal Anda berdampingan alih-alih memilih salah satu untuk Anda. Jika angkanya sudah ada dan Anda ingin memeriksanya dengan mata, tempelkan ke bidang di puncak halaman ini.