Waktu yang Berlalu Sejak Epoch

• POSIX time/Unix time sering disebut sebagai jumlah detik sejak 1970-01-01 00:00:00, tetapi sebenarnya merupakan nilai berbasis UTC yang mengabaikan detik kabisat, sehingga menyimpang dari detik yang benar-benar berlalu
• Per 2024-12-25 18:51:26 UTC, POSIX time adalah 1735152686, sedangkan detik yang benar-benar berlalu sejak epoch adalah 1735152713 detik, selisih 27 detik
• IEEE 1003.1 mendefinisikan seconds since the Epoch dengan selalu menghitung satu hari sebagai 86.400 detik, dan lampiran standarnya juga mengabaikan 14 detik kabisat yang ditambahkan sejak 1970 demi kompatibilitas dan kemudahan perhitungan
• UTC menambahkan detik kabisat untuk mengurangi selisih dengan hari matahari, dan saat itu POSIX time melompat mundur sehingga pernah memicu insiden seperti Linux, Qantas, dan Cloudflare DNS
• Untuk mengukur interval waktu pada satu komputer, CLOCK_MONOTONIC atau CLOCK_BOOTTIME lebih baik; jika harus selaras dengan POSIX timestamp, pertimbangkan leap smear atau konversi POSIX↔TAI

---

POSIX time bukan jumlah detik yang benar-benar berlalu

• JavaScript Date, GNU coreutils, Linux time(2), Go time.Unix, MySQL datetime, Ruby Time, Cassandra timestamp, dan lainnya sering memperlakukan POSIX time seperti jumlah detik sejak Unix epoch
• Namun ungkapan ini tidak sepenuhnya sesuai dengan intuisi umum
  • Contoh waktu: 2024-12-25 18:51:26 UTC
  • POSIX time: 1735152686
  • Detik yang benar-benar berlalu sejak POSIX epoch: 1735152713
  • Selisih: 27 detik
• Selisih ini muncul karena POSIX time, meski diturunkan dari UTC dalam IEEE 1003.1, mengasumsikan semua hari tepat 86.400 detik
• Definisi standar untuk seconds since the Epoch menghitung nilai menggunakan tm_sec, tm_min, tm_hour, tm_yday, dan tm_year, serta tidak mendefinisikan hubungannya dengan tahun sebelum 1970 atau nilai negatif
• Panjang satu hari sebenarnya tidak selalu 86.400 detik dan berubah seiring waktu
  • Para astronom secara berkala menetapkan detik kabisat agar tanggal UTC tidak terlalu jauh dari hari matahari
  • Akibatnya, POSIX time dapat melompat mundur setiap beberapa tahun
  • Suatu saat, POSIX time juga bisa melompat maju
• Detik kabisat pernah menyebabkan gangguan nyata
  • Masalah detik kabisat terkait kernel Linux
  • Keterlambatan Qantas akibat bug detik kabisat Linux
  • Dampak detik kabisat pada Cloudflare DNS

Kompromi standar dan alternatif praktis

• Lampiran B IEEE 1003 merangkum bahwa pada saat standar diterbitkan, 14 detik kabisat telah ditambahkan sejak 1970-01-01, tetapi 14 detik ini diabaikan demi perhitungan yang mudah dan kompatibilitas
• Standar memandang nilai “time” pada sebagian besar sistem terus meningkat, dan memilih agar nilai ini tetap meningkat bahkan selama detik kabisat
  • Pada saat yang sama, standar mengasumsikan bahwa sebagian besar sistem mungkin tidak melacak detik kabisat atau tidak tersinkronisasi dengan acuan waktu standar
  • Karena itu, standar tidak menuntut seconds since the Epoch harus selalu menunjukkan jumlah detik yang tepat antara waktu acuan dan epoch
  • Cukup jika aplikasi dapat memperlakukan nilai ini seperti jumlah detik sejak epoch; tingkat akurasi yang diperlukan menjadi tanggung jawab vendor sistem dan administrator
• Dalam aplikasi terdistribusi, karena timestamp digunakan untuk menyinkronkan event, interpretasi yang konsisten bisa menjadi penting
  • Akumulasi detik kabisat tidak dapat diprediksi
  • Jumlah detik kabisat sejak epoch kemungkinan akan bertambah
  • Standar lebih berfokus pada sinkronisasi waktu antar-aplikasi dalam rentang yang singkat secara astronomis
• Sistem nyata umumnya tetap berjalan meski waktunya sedikit meleset, tetapi detik kabisat jarang terjadi dan intuisi linear bahwa ini adalah “jumlah detik sejak epoch” sangat kuat, sehingga bug yang belum ditemukan bisa menumpuk
• Alternatif sesuai situasi adalah sebagai berikut
  • Jika hanya menghitung duration antara dua event pada satu komputer, gunakan CLOCK_MONOTONIC, atau lebih jauh lagi CLOCK_BOOTTIME
  • Jika tidak perlu bertukar timestamp dengan sistem lain yang mengasumsikan POSIX time, gunakan TAI, GPS, LORAN
  • Jika perlu kira-kira selaras dengan sistem POSIX timestamp, gunakan leap smear untuk menyebarkan detik kabisat ke rentang waktu yang lebih panjang
  • Konversi antara POSIX dan TAI dapat dilakukan dengan library seperti t-a-i dari qntm
• Upaya untuk menghapus detik kabisat sedang berlangsung, dan diharapkan terwujud paling lambat 2035
  • Diperlukan pekerjaan tambahan untuk memasukkan tabel konversi ke semua hal yang bergantung pada asumsi satu hari 86.400 detik
  • Untuk waktu setelah 2035, pertanyaan seperti “berapa detik di antara dua waktu” bisa menjadi jauh lebih sederhana

[GN⁺]

Komentar Hacker News

• Saya baru saja membaca novel fiksi ilmiah Vernor Vinge tahun 2000, A Deepness in the Sky, dan ternyata itu buku yang luar biasa dengan penyebutan tak terduga tentang detik sejak epoch (seconds since the epoch)
  Dimulai dengan “Lihat cara para Traders mengukur waktu…”, lalu digambarkan bahwa Qeng Ho menghitung dalam satuan detik sejak momen umat manusia pertama kali menginjakkan kaki di bulan Old Earth, tetapi jika dilihat lebih rinci, titik awalnya sebenarnya sekitar 15 juta detik setelah itu—detik ke-0 dari salah satu sistem operasi komputer awal umat manusia

  • Buku ini secara pribadi salah satu favorit saya sepanjang masa, dan saya sangat suka caranya memakai referensi perangkat lunak yang halus
    Jika ingin lebih banyak “ilmu komputer di ruang angkasa”, saya merekomendasikan seri Bobiverse; jika ingin lebih banyak eksplorasi “manusia + simulasi + komputer”, saya merekomendasikan Permutation City

• Setiap kali membaca tentang pengukuran waktu, selalu saja saya belajar hal baru. Saya selama ini mengira waktu Unix adalah cara paling sederhana untuk melacak waktu selama hanya memperhitungkan rollover, dan saya tahu tentang detik kabisat, tetapi tidak terpikir bahwa itu juga berlaku di sini
  Saya juga membaca tautan “UTC, GPS, LORAN and TAI”, dan kontrasnya menarik: waktu GPS tidak mencerminkan detik kabisat

  • Mengatakan bahwa sesuatu terjadi beberapa detik sebelum/sesudah itu sederhana. Yang sulit adalah menetapkan titik waktu itu sebagai tanggal kalender
  • Pada akhirnya saya melihat TAI sebagai yang paling sederhana, dan format lain sebaiknya dikonversi dari TAI hanya saat diperlukan. Misalnya untuk tampilan atau interoperabilitas

• Saya kurang suka rencana “upaya untuk menghapus detik kabisat hingga 2035”
  Inti UTC adalah berjarak sejumlah detik bulat dari TAI dan mendekati waktu surya rata-rata (MST). Jika tidak lagi melacak MST, seharusnya langsung saja beralih ke TAI
  Jika UTC dibiarkan menjauh dari MST, detik kabisat masa lalu tetap harus ditangani, tetapi detik kabisat itu tidak lagi punya tujuan—menjadi keadaan menggantung

  • Saya setuju bahwa menjauh dari MST biayanya lebih besar daripada manfaatnya
    Namun usulan ini bukan sepenuhnya tanpa arti. Tujuannya adalah tidak mengubah pengelolaan waktu UTC yang sudah ada, sambil membuat selisih dua timestamp setelah 2035 menjadi jumlah detik fisik yang tepat
    Meski begitu, karena MST sudah menjadi fungsi UTC, menghapusnya terasa konyol
  • Dalam dunia ideal, sistem komputer seharusnya memakai TAI untuk melacak waktu, lalu menggunakan basis data TZ untuk mengonversinya ke UTC atau waktu lokal
    Namun di dunia nyata, banyak sistem membuat pilihan yang keliru, dan UNIX khususnya adalah penyebab terbesar. Pilihan itu sudah tertanam begitu dalam di begitu banyak sistem dan regulasi sehingga “langsung beralih ke TAI” praktis mustahil
    Karena itu, lebih mudah menafsirkan ulang UTC sebagai “TAI baru”. Saya tidak akan terkejut jika suatu hari UTC lama muncul kembali dengan nama lain
  • Tidak ada entitas terpisah bernama TAI. TAI adalah apa yang didapat jika memulai dari UTC lalu mengurangi jumlah detik kabisat yang relevan. TAI tidak dipelihara sebagai besaran standar yang terpisah
    Di sebagian besar atau semua negara, waktu sipil berbasis UTC. Tidak ada yang akan memundurkan jam seluruh dunia sekitar 30 detik hanya karena itu sedikit lebih murni
    Waktu GPS juga punya offset terhadap TAI, tetapi tidak ada yang terlalu peduli. Unix epoch juga sama; asalkan hasilnya konsisten, itu cukup
  • Peretasannya secara harfiah sepele. Sebulan sekali, periksa apakah UTC # ET; jika berbeda, buat file bernama Leap_Second. Setiap bulan periksa apakah file ini ada; jika ada, hapus, lalu tambahkan 1 ke nilai file Leap_Seconds dan buat cadangan bernama LSSE
    “You are not expected to understand this.” Ini cara mempertahankan kedua sistem. Jika mau, bisa juga dibuat dengan hash atau tabel lookup

• Penting juga bahwa UTC epoch modern adalah 1 Januari 1972. Sebelum itu, UTC menggunakan panjang detik yang berbeda dari TAI
  Pada akhir 1971, sebagai tahap peralihan, ada lompatan tidak beraturan terakhir sebesar tepat 0,107758 detik TAI, dan total penyesuaian langkah waktu kecil serta frekuensi UTC atau TAI sepanjang 1958–1971 disetel agar tepat menjadi 10 detik. Jadi 1 Januari 1972 00:00:00 UTC tepat sama dengan 1 Januari 1972 00:00:10 TAI, dan sejak itu selisihnya berupa detik bulat
  Pada saat yang sama, laju tick UTC menjadi persis sama dengan TAI, dan UTC mulai melacak UT1, bukan UT2. Karena itu, waktu Unix pada 1970 dan 1971 tidak cocok dengan waktu UTC sebenarnya pada periode tersebut
  https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His...
  https://en.wikipedia.org/wiki/Unix_time#UTC_basis

  • Karena hal ini, ada orang yang masih hidup hari ini yang tidak bisa mengetahui usia tepatnya (dalam detik), dan tidak akan pernah bisa mengetahuinya
    Bahkan dengan asumsi waktu pada akta kelahirannya akurat hingga detik. Sebab selama sebagian masa hidup orang itu, nilai yang dianggap sebagai “panjang 1 detik” cukup berbeda dibandingkan 1 detik yang biasanya kita pikirkan sekarang
    Detik di sini berarti detik berdasarkan frekuensi transisi hiperhalus keadaan dasar tak terganggu atom cesium-133 sebesar 9.192.631.770/s

• Baru-baru ini saya menulis kode untuk sebuah bursa, dan sistemnya berjalan di atas VAX, atau tepatnya OpenVMS, dengan epoch 17 November 1858
  Itu pertama kalinya dalam karier saya melihat epoch selain Unix, dan untungnya kode yang digunakan sudah diabstraksikan ke Unix epoch

  • Epoch 1858 tampaknya berasal dari Julian Day, kalender standar astronomi. Di sini hari ke-0 adalah tahun 4713 SM
    https://www.slac.stanford.edu/~rkj/crazytime.txt
    Untuk memasukkan tanggal-tanggal ini ke memori komputer pada 1950-an, kalender digeser sebesar 2,4 juta hari, sehingga hari ke-0 menjadi 17 November 1858
  • Ada juga anekdot lama Microsoft tentang bentrokan antara epoch Excel, 1 Januari 1900, dan Basic, 31 Desember 1899
    https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
  • Sistem komputasi umum lain yang patut diketahui: Windows epoch adalah 1 Januari 1601
  • Classic MacOS, sistem berkas HFS milik Apple (juga digunakan di OS X), dan PalmOS semuanya memiliki epoch 1 Januari 1904
    API macOS/Swift Foundation NSDate.timeIntervalSinceReferenceDate menggunakan 1 Januari 2001 sebagai epoch
    Wikipedia juga punya daftar yang berguna: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
  • PostgreSQL secara internal menggunakan epoch 2000-01-01 untuk menyimpan timestamp

• Ada titik waktu yang tidak bisa direpresentasikan sebagai timestamp POSIX, dan ada timestamp POSIX yang tidak lagi sesuai dengan waktu nyata

  • Saya penasaran timestamp POSIX mana yang tidak sesuai dengan waktu nyata. Atau maksudnya jika di masa depan ada detik kabisat negatif?
  • Ini memang selalu begitu. Dalam waktu Unix, sebelum 1970 tidak didefinisikan
  • Tapi setidaknya tidak ada satu timestamp POSIX yang berkorespondensi dengan lebih dari satu titik waktu nyata. Itu lebih baik daripada satu format representasi yang dipakai orang untuk segala hal
  • Tidak begitu
    Itu mirip seperti mengatakan ada titik waktu yang tidak punya tahun ISO 8601. Semua titik waktu punya tahun, hanya saja sebagian tahun lebih panjang daripada yang lain
    Kalau duduk dan memperhatikan https://time.is/UTC, waktu akan bertambah secara monoton, dan sesekali ada detik yang sedikit lebih panjang. Misalnya sekitar 0,001% lebih panjang selama 24 jam

• Saat menyimpan tanggal di database, saya selalu menyimpannya sebagai waktu Unix epoch, dan tidak mencatat informasi zona waktu di field tanggal. Jika ada kebutuhan untuk mengetahui zona waktu, saya menyimpannya terpisah
  Saya bertanya-tanya apakah seharusnya timestamp justru disimpan dalam format TAI, lalu memakai fungsi untuk mengonversinya ke UTC saat diperlukan, agar koreksi terkait Bumi bisa ditangani ketika dibutuhkan
  Saya tahu zona waktu itu ladang ranjau, tetapi itu juga konstruksi manusia yang batas-batasnya berubah seiring waktu. Rasanya sebaiknya dipatok ke waktu absolut, lalu dirender ke format waktu lokal yang diinginkan saat diperlukan

  • Benar. TAI atau format serupa adalah satu-satunya cara masuk akal untuk melacak waktu “sistem”, dan sistem tingkat lebih tinggi harus mengubahnya menjadi waktu yang dilihat manusia
    Penyesuaian detik kabisat seharusnya terjadi di tempat yang sama dengan konversi zona waktu. Sayangnya Unix menstandarkan hal yang keliru, dan migrasi itu sulit
  • Umumnya tidak, dan hampir selalu tidak. Kebanyakan software ditulis untuk menangani detik kabisat dengan menimpanya, dan dalam praktiknya itu hanya terjadi di lapisan sinkronisasi jam. Misalnya chrony mengimplementasikan leap-second smearing
    Jadi semua jam bagaimanapun diselaraskan ke UTC. Kalau saat menyimpan harus mengonversi dari UTC ke TAI, lalu saat membaca mengembalikannya lagi, itu akan jadi berantakan
  • Mengenai bagian “tidak mencatat informasi zona waktu di field tanggal”, sebenarnya sangat sedikit database yang memungkinkan pelestarian zona waktu pada kolom timestamp
    Biasanya database tidak punya konsep zona waktu untuk timestamp yang disimpan (SQL Server), atau menyediakan tipe timestamp “sadar zona waktu” tetapi mengonversi input ke UTC dan membuang zona waktu aslinya (MySQL, Postgres)
    Sejauh yang saya tahu, hanya Oracle yang benar-benar bisa melakukan round-trip dan mempertahankan zona waktu non-lokal pada tipe with time zone
  • Tergantung apa yang disimpan sistemnya. Kebanyakan sistem tidak peduli jika meleset 1 detik setiap beberapa tahun
    Dalam sebagian perhitungan, selisih 1 detik adalah masalah besar. Saat mengadopsi format yang bukan paling umum dipakai, harus berhati-hati, dan harus ada alasan kuat untuk menyimpang dari standar. Sekadar fakta bahwa formatnya berbeda saja bisa menimbulkan biaya besar
  • Pakai saja field tanggal-waktu native dari database

• Rasanya Natal saya rusak gara-gara tulisan ini. Apakah tidak ada yang suci? Detik seharusnya adalah detik sejak epoch
  Saya tidak mengerti kenapa harus peduli kalau sedikit melenceng dari hari matahari. Bukankah konverter yang mengubah detik sejak epoch menjadi representasi tanggal bisa bertanggung jawab atas koreksinya?

  • Cara saat ini sebenarnya adalah cara yang kita inginkan. 86400 detik = 1 hari, dan kita beroperasi dengan asumsi bahwa tengah malam UTC selalu kelipatan 86400
    Kita tidak ingin semua software harus meng-hardcode penerapan detik kabisat, menangani smearing, dan menuntut cara update dalam satu bulan setiap kali detik kabisat baru diperkenalkan
    Selama ini kita tidak perlu khawatir atau memikirkannya, dan ke depannya juga tidak perlu. Ini ditangani dengan cara yang benar

• Detik kabisat seharusnya diganti dengan roket raksasa yang dipasang di khatulistiwa. Jangan sesuaikan jam; sesuaikan planetnya

  • Kalau karena salah hitung Bumi jadi terlalu lambat atau terlalu cepat, sepertinya tidak akan terlalu lucu
    Dalam tradisi Islam tentang akhir zaman dan Dajjal juga ada bagian yang menggambarkan hal seperti ini benar-benar terjadi. “Hari pertama Dajjal akan seperti setahun, hari keduanya seperti sebulan, dan hari ketiganya seperti sepekan,” dan banyak orang memahaminya secara harfiah, yaitu sebagai peristiwa kosmik ketika rotasi Bumi benar-benar melambat dan akhirnya berbalik arah sehingga matahari terbit dari barat. Itu adalah tanda terakhir akhir umat manusia

• Saya merasa, apa masalahnya kalau karena detik kabisat, epoch menjadi 29 detik lebih lama dari yang diisyaratkan oleh date +%s?
  Fakta bahwa semua orang sepakat pada suatu angka N yang merepresentasikan waktu saat ini jauh lebih penting. -29 detik imajiner tidak memengaruhi dunia nyata. Lagi pula, bukankah kita tidak akan menjalankan rutinitas pembidikan misil untuk target 30 tahun lalu?
  Saya mendukung penghapusan detik kabisat, tetapi saya tidak melihat penekanan pada ketidaksesuaian waktu sebagai hal yang berguna. Sekalipun, jika ditelaah, itu memang benar

  • Bisa dibayangkan situasi ketika durasi peristiwa singkat dihitung dari waktu mulai/selesai. Jika rentang itu melewati detik kabisat, bergantung pada cara timestamp diproses, durasi bisa cukup berbeda
    Yang lebih penting adalah dampaknya pada masa depan. Bahwa timestamp masa lalu bisa berbeda beberapa detik dari perhitungan sederhana “sekarang - N detik” bagi kebanyakan orang lebih mirip fakta menarik, tetapi bahwa pada suatu saat di masa depan semua jam mungkin harus bergeser 1 detik lagi itu lebih penting. Ada banyak contoh nyata yang membutuhkan upaya cukup besar untuk memperhitungkan hal ini
  • Ini penting untuk beberapa hal. Tanpa detik kabisat imajiner seperti itu, misalnya posisi matahari pada tengah hari setempat akan melenceng sebesar 29 detik