FlowingDev

Epoch Time, Dijelaskan: Jam yang Cuma Bisa Maju

Pelajari apa itu waktu Unix (atau Epoch time): jumlah detik yang telah berlalu sejak 1 Januari 1970, yang digunakan komputer untuk melacak waktu secara universal.

Coba tool-nya: Pengonversi Epoch

Dalam satu kalimat

Epoch time adalah cara komputer melacak waktu sebagai satu angka yang terus bertambah: jumlah total detik yang telah berlalu sejak tengah malam UTC pada 1 Januari 1970.

Masalah yang dipecahkannya

Manusia dan waktu punya hubungan yang rumit. Kita punya zona waktu, daylight saving, dan format seperti BB/HH/TTTT vs. HH/BB/TTTT. Kita menulis "8 Oktober 2024 jam 3:00 sore," tapi itu artinya beda di Tokyo dan di Toronto. Pokoknya ribet dan ambigu.

Komputer, sebaliknya, benci banget sama yang namanya ambiguitas. Mereka butuh satu cara yang universal dan sederhana secara matematis untuk merepresentasikan sebuah momen. Mencoba menghitung matematika dengan "8 Oktober" itu mimpi buruk. Tapi kalau berhitung dengan angka biasa? Nah, itu baru jagonya komputer.

Inilah masalah yang coba dipecahkan oleh waktu Unix (juga disebut Epoch time atau waktu POSIX). Dulu di awal-awal sistem operasi Unix pada tahun 1970-an, para penciptanya butuh sistem pencatat waktu yang praktis. Mereka memutuskan untuk memilih titik awal yang seenaknya—sebuah "epoch"—dan ya udah... hitung aja terus.

Epoch yang dipilih adalah 00:00:00 UTC, 1 Januari 1970. Kenapa tanggal itu? Ya karena angkanya bagus, dan cukup baru untuk teknologi saat itu.

Sejak saat itu, setiap detik yang berlalu akan menambah sebuah penghitung universal. Jadi, daripada komputer harus mem-parsing "jam 3:00 sore pada 8 Oktober 2024, di Toronto (yang merupakan EDT)," ia cukup menyimpan angka 1728409200. Angka itu merepresentasikan momen yang tepat sama, di mana pun di Bumi, secara serentak. Nggak ada zona waktu, nggak ada format, nggak ada "ini pagi atau malam?". Cuma angka. Masalah beres.

Cara kerjanya di balik layar

Pada dasarnya, konsepnya simpel banget. Tapi seperti biasa di dunia teknologi, seluk-beluknya itu yang bikin pusing.

Epoch dan Unitnya

Seluruh sistem ini dibangun di atas dua ide:

  1. Titik Awal (Epoch): Ini ditetapkan pada 1970-01-01T00:00:00Z. Huruf Z berarti Zulu, istilah militer dan penerbangan untuk UTC (Coordinated Universal Time). Dalam dunia Epoch time, momen ini adalah angka 0.
  2. Unit Pengukuran: Standar unit resminya adalah detik.

Jadi, timestamp 1 merepresentasikan 1970-01-01T00:00:01Z. Timestamp untuk awal hari berikutnya, 1970-01-02T00:00:00Z, adalah 86400 (karena ada 60 detik * 60 menit * 24 jam = 86.400 detik dalam sehari).

// Tanggal jauh di masa depan
const humanDate = new Date('2035-10-26T10:00:00Z');

// Timestamp Epoch yang sesuai dalam detik
const epochTimestamp = 2071754400;

Saat komputer Anda menunjukkan timestamp ini sebagai waktu lokal, di balik layar ia melakukan konversi. Komputer mengambil timestamp UTC universal dan menerapkan selisih zona waktu sistem Anda untuk menampilkannya dengan cara yang masuk akal bagi Anda. Tapi, angka dasarnya tetap murni dan universal.

Variasi: Milidetik, Mikidetik, Nanodetik

Terkadang, Anda perlu mengukur hal-hal yang terjadi lebih cepat dari satu detik. Untuk ini, sistem menggunakan versi timestamp Epoch yang lebih presisi. Prinsipnya sama, tapi unitnya berubah.

Unit Contoh Nilai (untuk momen yang sama) Jumlah Digit Umum Kasus Penggunaan Umum
Detik 1728409200 10 Standar POSIX; API, database.
Milidetik 1728409200123 13 JavaScript (Date.now()), API modern.
Mikidetik 1728409200123456 16 Sistem performa tinggi, beberapa database.
Nanodetik 1728409200123456789 19 Komputasi ilmiah, bahasa Go.

Ini adalah sumber bug nomor satu saat bekerja dengan timestamp. Jika sebuah sistem memberi Anda angka 13 digit dan Anda menganggapnya sebagai detik, Anda sedang mencoba menghitung tanggal ribuan tahun di masa depan. Selalu cek dokumentasi atau lihat jumlah digitnya untuk tahu apa yang sedang Anda hadapi.

"Masalah Tahun 2038"

Ini dia salah satu cerita klasik di dunia komputer. Banyak sistem lawas, untuk menghemat memori yang berharga, menyimpan timestamp Epoch sebagai integer 32-bit bertanda (signed).

"Bit" adalah 1 atau 0. "32-bit" berarti Anda punya 32 slot untuk 1 dan 0. "Signed" berarti salah satu bit itu digunakan untuk menandakan apakah angkanya positif atau negatif. Ini menyisakan 31 bit untuk angkanya sendiri, yang bisa merepresentasikan nilai maksimum 2^31 - 1, atau 2.147.483.647.

Apa yang terjadi saat jumlah detik sejak 1970 mencapai batas itu? Itu akan terjadi pada Selasa, 19 Januari 2038, pukul 03:14:07 UTC. Pada detik berikutnya, integer tersebut akan overflow. Kayak odometer mobil yang balik dari 999999 ke 000000, timestamp 32-bit akan berputar kembali ke nilai negatif paling besar (-2.147.483.648). Ini setara dengan tanggal di bulan Desember 1901.

Untuk sistem 32-bit mana pun yang belum di-patch, ini akan menyebabkan kekacauan kronologis. Bayangkan sistem embedded di mobil tua, peralatan industri, atau router jaringan.

Solusinya? Pakai integer 64-bit. Integer 64-bit bisa menyimpan angka yang luar biasa besar sehingga tidak akan overflow selama sekitar 292 miliar tahun. Saat itu, matahari sudah lama mengembang dan menelan Bumi, jadi kayaknya bisa kita sebut solusi permanen. Sebagian besar sistem operasi dan bahasa pemrograman modern sudah beralih.

Detik Kabisat: Kerikil dalam Sistem

Rotasi Bumi tidak sepenuhnya teratur; ia sedikit melambat. Agar jam atom kita (yang super teratur) tetap sinkron dengan hari matahari, badan-badan internasional sesekali menambahkan "detik kabisat" ke kalender. Ini berarti satu menit bisa saja memiliki 61 detik (misalnya, 23:59:60).

Jadi, gimana Epoch time menangani ini? Jawabannya: nggak ditangani.

Secara resmi, standar POSIX mengabaikan detik kabisat. Standar ini mengasumsikan setiap hari memiliki tepat 86.400 detik. Saat detik kabisat terjadi, sistem menanganinya dengan beberapa cara, tapi yang umum adalah dengan mengulangi detik sebelumnya secara efektif. Timestamp untuk 23:59:59 bisa terjadi dua kali. Ini menjaga hitungan detik yang kontinu dan tidak terputus, tapi berarti timestamp Unix tidak selalu bisa dipetakan kembali ke UTC dunia nyata dengan sempurna. Untuk 99,9% aplikasi, ini bukan masalah. Tapi untuk perdagangan frekuensi tinggi atau pengukuran ilmiah, ini bikin pusing tujuh keliling.

Cerita dari dunia nyata

Kasus Cache yang Bisa Jalan-Jalan di Waktu

Sebuah tim developer sedang meluncurkan fitur baru yang didukung oleh sistem caching. Untuk meningkatkan performa, mereka men-cache data selama satu jam. Logikanya sederhana: waktu_kadaluarsa = waktu_sekarang() + 3600. Mereka men-deploy kode tersebut ke semua server mereka.

Tiba-tiba, bug aneh membanjiri. Data menghilang dari cache hampir seketika. Setelah berjam-jam ngoprek panik, mereka menemukan biang keroknya. Salah satu server baru di armada mereka jam sistemnya tidak diatur dengan benar—jamnya berjalan lima menit lebih lambat dari semua server lain.

Saat permintaan pengguna mendarat di server yang benar, server itu akan men-cache data dengan waktu kedaluwarsa, katakanlah, 1678886400 (jam 12:00 siang). Jika permintaan berikutnya untuk data yang sama mendarat di server yang "lambat", jamnya menunjukkan 11:55 pagi. Saat server itu memeriksa cache, ia melihat waktu kedaluwarsa jam 12:00 siang dan dengan benar menyajikan data. Tapi jika permintaan pertama mendarat di server yang lambat, server itu akan menetapkan waktu kedaluwarsa 1678882800 (11:00 pagi, menurut waktunya sendiri, ditambah satu jam menjadi 12:00 siang). Padahal waktu sebenarnya sudah 11:55 pagi. Tunggu, ini nggak bener.

Coba kita ulangi. Waktu Server A adalah 12:00. Ia menetapkan kedaluwarsa cache pada 12:00 + 1 jam = 13:00. Jam Server B lambat; ia pikir sekarang jam 11:55. Saat Server B perlu menulis ke cache, ia menetapkan kedaluwarsa 11:55 + 1 jam = 12:55. Sekarang, jika Server A melihat item yang kedaluwarsa pada 12:55, ia akan berpikir item itu masih punya 55 menit, sementara Server B berpikir masih punya satu jam penuh. Ini menyebabkan inkonsistensi.

Kekacauan sebenarnya dimulai saat jamnya sangat jauh berbeda. Jika jam Server B satu jam lebih lambat (pikirnya jam 11:00 padahal sudah jam 12:00), ia akan menetapkan waktu kedaluwarsa 11:00 + 1 jam = 12:00. Dari sudut pandang Server A, item cache baru ini kedaluwarsa di detik yang sama saat dibuat. Data itu pun lenyap seketika.

Pelajaran: Timestamp Unix memang absolut, tapi ia dihasilkan dari jam sistem yang mungkin tidak sinkron. Dalam sistem terdistribusi, menjaga jam tetap sinkron (biasanya dengan Network Time Protocol, atau NTP) bukan cuma praktik yang baik; itu krusial.

API yang Ngomongnya Pakai Milidetik

Seorang developer frontend sedang membangun dasbor untuk menampilkan aktivitas pengguna. API backend menyediakan field last_login dengan timestamp, seperti 1678886400. Developer itu menggunakan library JavaScript untuk menampilkannya: new Date(1678886400).

Hasilnya aneh. Login terakhir setiap pengguna ditampilkan sebagai "20 Januari 1970." Apa yang terjadi?

Si developer pusing seharian, nyalahin library-nya, kodenya, sampai fase bulan. Akhirnya, dia mencoba mengintegrasikan endpoint lain dari API yang sama. Kali ini, timestamp-nya adalah 1678886400123. Ada 13 digit! Tiba-tiba, 'klik', dia sadar. Konstruktor objek Date di JavaScript mengharapkan timestamp dalam milidetik, bukan detik.

Backend mengirimkan timestamp standar 10 digit berbasis detik. Frontend menginterpretasikan 1.678.886.400 sebagai jumlah milidetik sejak epoch, yang merupakan tanggal beberapa minggu setelah epoch dimulai pada tahun 1970. Perbaikannya sederhana: new Date(1678886400 * 1000).

Pelajaran: Selalu, selalu, dan selalu verifikasi presisi sebuah timestamp. Beda tiga angka nol itu bedanya antara hari ini dan tahun 1970.

Kesalahan dan jebakan umum

  • Lupa soal zona waktu. Timestamp Unix selalu, tanpa kecuali, dalam UTC. Saat Anda mengubahnya menjadi tanggal yang bisa dibaca manusia, bahasa pemrograman atau alat Anda hampir selalu akan menggunakan zona waktu lokal komputer Anda. Ini bisa menyebabkan kebingungan besar jika Anda tidak memperhitungkannya. 1728409200 adalah satu momen yang tepat, tapi akan ditampilkan sebagai 06:00 di New York dan 19:00 di Tokyo. Angkanya adalah kebenaran; tampilannya adalah interpretasi.

  • Mencampuradukkan detik dan milidetik. Ini adalah kesalahan klasik "salah kelipatan 1000". Ini adalah bug paling umum saat bekerja dengan timestamp. Aturan praktisnya: 10 digit itu detik, 13 digit itu milidetik. Jika Anda melihat yang lain, curigalah.

  • Mengabaikan masalah Tahun 2038. Jika Anda membangun aplikasi web standar dengan bahasa modern, Anda mungkin aman. Tapi jika Anda menulis kode C untuk perangkat IoT embedded, sistem infotainment mobil, atau merawat sistem 32-bit lawas, bug Y2038 adalah bom waktu yang sangat nyata dan terus berdetik.

  • Pakai string ambigu untuk membuat timestamp. Membuat timestamp dari string seperti "15 Maret 2025 10:00 Malam" itu cari masalah. Apakah itu di zona waktu lokal Anda? Zona waktu server? UTC? Selalu buat timestamp dari objek yang sadar zona waktu atau gunakan string UTC yang eksplisit (seperti format ISO 8601: 2025-03-15T22:00:00Z).

Kenapa ini penting buat kamu

Mustahil jadi developer modern tanpa paham Epoch time. Ini adalah lingua franca alias bahasa universal waktu dalam komputasi. Anda akan menemuinya di mana-mana:

  • API: Payload JSON sering menggunakannya untuk field seperti createdAt, updatedAt, dan expires_at.
  • JWT: Klaim exp (kedaluwarsa), iat (diterbitkan pada), dan nbf (tidak sebelum) semuanya adalah timestamp Unix standar.
  • Database: Menyimpan waktu sebagai satu integer seringkali lebih efisien untuk pengindeksan dan penyimpanan daripada menggunakan tipe DATETIME yang kompleks.
  • File Log: Menggunakan timestamp numerik membuatnya sangat mudah untuk menghubungkan kejadian di puluhan server dan layanan yang berbeda, bahkan jika mereka berada di zona waktu yang berbeda.
  • File System: Sebagian besar file system menyimpan tanggal pembuatan dan modifikasi file sebagai timestamp Unix.

Memahami cara kerjanya memungkinkan Anda men-debug seluruh kelas bug rumit yang berhubungan dengan waktu dengan percaya diri. Ini memungkinkan Anda menembus dunia waktu manusia yang berantakan dengan zona waktu dan kalendernya, dan berpikir tentang waktu seperti cara komputer: sebagai barisan angka yang simpel dan teratur.

Gali lebih dalam

Teori beres. Saatnya praktik — 100% di browser kamu.

Coba tool-nya: Pengonversi Epoch