Apa Itu Unix Timestamp?

Unix timestamp adalah satu angka: hitungan detik yang telah berlalu sejak epoch Unix, yang didefinisikan sebagai 00:00:00 UTC pada 1 Januari 1970. Itu saja. Tidak ada zona waktu, tidak ada string tanggal, tidak ada nama bulan — hanya bilangan bulat yang bertambah satu unit setiap detik.

Karena epoch bersifat tetap dan universal, timestamp seperti 1700000000 berarti momen yang persis sama di mana pun di Bumi. Server di Tokyo dan laptop di Chicago sama-sama akan setuju bahwa itu merujuk pada 14 November 2023 pukul 22:13:20 UTC. Tampilan lokal berbeda menurut zona waktu, tetapi angka dasarnya tidak pernah berubah.

Satu penyederhanaan yang disengaja: Waktu Unix mengabaikan detik kabisat. Waktu ini mengasumsikan setiap hari tepat 86.400 detik, yang tidak sepenuhnya benar secara astronomi, tetapi menjaga perhitungan tetap bersih. Lebih lanjut tentang itu di bawah.

Mengapa Para Insinyur Menyukainya

Timestamp ada di mana-mana dalam perangkat lunak — waktu modifikasi file, catatan basis data, respons API, bidang kedaluwarsa JWT, baris log — dan untuk alasan yang baik:

• Itu adalah nilai tunggal. Satu bilangan bulat menyimpan tanggal dan waktu lengkap. Tidak perlu penguraian, tidak ada ambiguitas tentang MM/DD versus DD/MM.
• Itu tidak bergantung pada zona waktu. Angka tersebut selalu UTC. Anda mengonversi ke waktu lokal hanya saat menampilkannya kepada manusia.
• Itu mudah dibandingkan dan diurutkan. Peristiwa mana yang terjadi lebih dulu? Bilangan bulat yang lebih kecil. Durasi antara dua peristiwa? Kurangi saja; jawabannya dalam detik.
• Itu disimpan secara ringkas. Satu bilangan bulat 4 atau 8 byte versus string yang diformat.

Inilah sebabnya mengapa begitu banyak infrastruktur menggunakan detik epoch di balik layar, bahkan ketika antarmuka menampilkan 2026-07-23 yang ramah. Jika Anda ingin berpindah di antara kedua representasi, pengubah stempel waktu Unix melakukan penerjemahan di kedua arah.

Membaca Satu: Contoh Kerja

Ambil timestamp 1000000000 — yang terkenal, karena melonjak di TV langsung di kalangan penggemar Unix.

Untuk membacanya secara manual, Anda membagi detik menjadi unit yang lebih besar. Secara kasar, 1.000.000.000 detik adalah sekitar 31,7 tahun (satu tahun ~31.556.952 detik). Tambahkan itu ke epoch 1970 dan Anda akan sampai di 2001. Momen tepatnya adalah 09 September 2001, 01:46:40 UTC.

Anda jarang melakukan aritmetika ini secara manual — setiap bahasa memiliki fungsi bawaan. Dalam Python:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

Poin utamanya: konversi selalu berpatokan pada UTC. Fungsi tersebut mengubah hitungan detik mentah menjadi tanggal kalender dengan bergerak maju dari epoch. Jika Anda menginginkan waktu lokal, Anda menerapkan offset zona waktu setelah konversi UTC — timestamp itu sendiri tidak membawa informasi zona.

Masalah Tahun 2038

Di sinilah ceritanya menjadi menarik — dan di mana banyak sistem yang sebenarnya dibangun dengan baik memiliki bom waktu di dalamnya.

Selama beberapa dekade, tipe standar C yang digunakan untuk menyimpan waktu Unix, time_t, biasanya berupa bilangan bulat 32-bit bertanda. Bilangan bulat 32-bit bertanda dapat mewakili nilai dari −2.147.483.648 hingga 2.147.483.647. Batas atas itulah masalahnya.

Menghitung detik dari epoch 1970, nilai 2.147.483.647 tercapai pada 03:14:07 UTC pada 19 Januari 2038. Satu detik kemudian, penghitung perlu menjadi 2.147.483.648 — tetapi angka itu tidak muat dalam bilangan bulat 32-bit bertanda. Alih-alih terus naik, bit-bit tersebut meluap dan berputar ke nilai paling negatif, yaitu −2.147.483.648.

Timestamp negatif diartikan sebagai waktu sebelum epoch. Jadi jam tidak hanya berhenti — jam melompat mundur ke 13 Desember 1901. Sistem apa pun yang mempercayai time_t 32-bit-nya tiba-tiba percaya bahwa itu adalah awal abad kedua puluh.

Ini sering disebut bug Y2K38 atau Bug Milenium Unix, dan secara struktural ini adalah jenis luapan lebar tetap yang sama yang mendorong ketakutan Tahun 2000 — hanya lebih jauh dan berakar pada batas bilangan bulat biner, bukan tahun dua digit.

Di Mana Ini Benar-Benar Menggigit

Desktop dan server 64-bit modern sebagian besar telah diperbaiki bertahun-tahun yang lalu. Risiko terkonsentrasi di tempat-tempat yang sulit diperbarui:

• Sistem tertanam dan industri. Router, pengontrol, perangkat medis, ECU otomotif, dan perangkat keras IoT yang dikirimkan dengan time_t 32-bit dan mungkin berjalan tanpa disentuh selama 20+ tahun. Banyak perangkat yang digunakan saat ini masih akan beroperasi pada tahun 2038.
• Kode C lawas. Aplikasi yang dikompilasi dengan definisi time_t lama, terutama ketika tipe tersebut merayap ke dalam format on-disk atau protokol jaringan.
• Basis data dan sistem file lama. Format penyimpanan yang mengemas timestamp ke dalam bidang 32-bit. Beberapa sistem lama sudah menunjukkan gejala saat menangani tanggal yang jauh di masa depan — pikirkan hipotek 20 tahun atau kedaluwarsa sertifikat yang mencapai setelah 2038.

Mode kegagalannya tidak selalu berupa kerusakan dramatis. Terkadang itu adalah tanggal yang dihitung salah: token kedaluwarsa yang terbaca valid, urutan pengurutan yang terbalik, pekerjaan terjadwal yang aktif pada tahun 1901.

Perbaikannya: Waktu 64-Bit

Solusinya mudah pada prinsipnya — lebarkan time_t menjadi 64 bit. Bilangan bulat 64-bit bertanda dapat menghitung detik jauh melampaui cakrawala praktis apa pun: titik luapan berada sekitar 292 miliar tahun di masa depan, dengan nyaman melewati perkiraan umur Matahari.

Sebagian besar sistem operasi saat ini telah melakukan langkah ini. Linux 64-bit menggunakan time_t 64-bit; bahkan Linux 32-bit telah mendapatkan dukungan waktu 64-bit di kernel dan glibc dalam beberapa tahun terakhir. Bagian yang sulit bukanlah perbaikannya sendiri — melainkan menemukan dan membangun ulang setiap bagian firmware, setiap format yang disimpan, dan setiap biner pihak ketiga yang masih mengasumsikan 32 bit. Pekerjaan audit itulah proyek 2038 yang sebenarnya.

Bagaimana Detik Kabisat Cocok

Waktu astronomi dan waktu atom sedikit berbeda, sehingga UTC resmi kadang-kadang menyisipkan detik kabisat untuk menjaga jam tetap selaras dengan rotasi Bumi. Waktu Unix, dengan sengaja, berpura-pura ini tidak ada — waktu ini menetapkan 86.400 detik per hari.

Ketika detik kabisat terjadi, sistem biasanya "mengoleskannya" — menyebarkan detik ekstra di seluruh jendela (Google mempopulerkan olesan 24 jam) sehingga tidak ada jam yang harus menampilkan 23:59:60 yang mustahil. Hasilnya: timestamp Unix tetap mulus dan monoton, dengan mengorbankan sedikit perbedaan sepersekian detik dari UTC yang ketat selama olesan. Untuk hampir semua perangkat lunak, ini adalah trade-off yang Anda inginkan. Luapan 2038 adalah masalah lebar bilangan bulat; detik kabisat adalah keanehan definisi yang terpisah dan jauh lebih kecil — jangan mencampuradukkannya.

Poin-Poin Penting

• Unix timestamp adalah detik sejak 00:00:00 UTC pada 1 Januari 1970, mengabaikan detik kabisat.
• Ini adalah bilangan bulat tunggal yang tidak bergantung pada zona waktu — mudah disimpan, dibandingkan, dan diurutkan.
• Konversi selalu relatif terhadap UTC; waktu lokal diterapkan setelahnya.
• time_t 32-bit bertanda meluap pada 03:14:07 UTC pada 19 Januari 2038, berputar ke nilai negatif dan melompat ke 1901.
• Perbaikannya adalah time_t 64-bit; usahanya adalah mengaudit sistem tertanam dan lawas.

Ingin melihatnya beraksi? Tempelkan nilai epoch apa pun ke pengubah stempel waktu Unix untuk membacanya sebagai tanggal manusia — atau sebaliknya, ubah tanggal menjadi timestamp-nya.

Pertanyaan yang Sering Diajukan

Apakah Unix timestamp dalam detik atau milidetik?

Waktu Unix klasik dalam detik. Namun, JavaScript dan banyak API web menggunakan milidetik sejak epoch, sehingga nilai seperti 1700000000000 adalah 1.000× lebih besar. Petunjuk cepat: timestamp berbasis detik untuk tanggal terkini memiliki 10 digit; yang berbasis milidetik memiliki 13 digit. Jika ragu, periksa besarnya sebelum mengonversi.

Akankah masalah Tahun 2038 merusak ponsel atau laptop saya?

Hampir pasti tidak. Sistem operasi 64-bit modern sudah menggunakan time_t 64-bit, yang mendorong luapan miliaran tahun ke depan. Paparan yang sebenarnya ada pada perangkat tertanam yang berumur panjang dan perangkat lunak lama yang masih mengandalkan waktu 32-bit dan mungkin tidak diperbarui sebelum 2038.

Bisakah Unix timestamp menjadi negatif?

Ya. Nilai negatif mewakili momen sebelum epoch 1970 — misalnya, -1 adalah 31 Desember 1969, 23:59:59 UTC. Inilah tepatnya yang dihasilkan oleh luapan 32-bit pada tahun 2038, itulah sebabnya jam tampak melompat kembali ke 1901.

Mengapa waktu Unix mengabaikan detik kabisat?

Untuk menjaga matematika tetap sederhana dan dapat diprediksi. Memperlakukan setiap hari sebagai tepat 86.400 detik berarti durasi hanyalah pengurangan, dan timestamp tetap monoton. Ketidakcocokan kecil dengan UTC astronomi ditangani dengan "mengoleskan" detik kabisat, yang hampir semua aplikasi lebih sukai daripada berurusan dengan kasus tepi 23:59:60.

Bagaimana cara mengonversi timestamp tanpa menulis kode?

Gunakan alat online. pengubah stempel waktu Unix menerima nilai epoch dan menampilkan tanggal-waktu UTC dan lokal yang cocok secara instan, dan juga mengonversi tanggal kalender kembali menjadi timestamp.