Waktu yang Berlalu Sejak Epoch

• Detik sejak Epoch

  • Waktu POSIX, atau waktu Unix, diketahui berarti jumlah detik sejak 1 Januari 1970 00:00:00. Namun, ini tidak tepat. Sebagai contoh, waktu POSIX untuk 25 Desember 2024 18:54:53 UTC adalah 1735152686, yang sebenarnya 29 detik lebih rendah daripada 1735152715 detik yang benar-benar telah berlalu.

  • Waktu POSIX diturunkan dari Coordinated Universal Time (UTC) dalam IEEE 1003.1. Standar tersebut mengasumsikan bahwa setiap hari tepat 86.400 detik. Namun kenyataannya, panjang satu hari tidak selalu 86.400 detik dan berubah seiring waktu. Untuk menyesuaikan hal ini, para astronom secara berkala menetapkan detik kabisat ke UTC.

• Arkeologi

  • Lampiran B dari IEEE 1003 memuat pembahasan menarik tentang detik kabisat. Saat standar itu diterbitkan, 14 detik kabisat telah ditambahkan sejak 1 Januari 1970. Detik-detik kabisat ini diabaikan agar selisih waktu dapat dihitung dengan mudah.

  • Sebagian besar sistem menganggap waktu sebagai nilai yang terus meningkat. Namun, kebanyakan sistem tidak melacak detik kabisat dan tidak disinkronkan ke referensi waktu standar. Karena itu, persyaratan bahwa detik sejak Epoch harus secara akurat merepresentasikan detik antara waktu yang dirujuk dan Epoch menjadi tidak tepat.

  • Interpretasi yang konsisten atas detik sejak Epoch dapat menjadi penting untuk jenis aplikasi terdistribusi tertentu. Akumulasi detik kabisat tidak dapat diprediksi, dan jumlah detik kabisat sejak Epoch kemungkinan akan terus bertambah.

• Apa yang sebaiknya dilakukan

  • Untuk menghitung durasi antara dua peristiwa pada satu komputer, Anda sebaiknya menggunakan CLOCK_MONOTONIC. Jika tidak perlu bertukar waktu POSIX dengan sistem lain, Anda dapat menggunakan TAI, GPS, atau LORAN.

  • Jika diperlukan penyelarasan kasar dengan sistem stempel waktu POSIX, detik kabisat dapat disebarkan ke rentang waktu yang lebih panjang. Pustaka seperti qntm t-a-i mendukung konversi antara POSIX dan TAI.

  • Upaya untuk menghapus detik kabisat sedang berlangsung, dan diharapkan selesai pada 2035. Ini akan memerlukan pekerjaan tambahan untuk membangun tabel konversi bagi semua hal yang menggunakan asumsi "86.400 detik per hari", tetapi akan membuat pertanyaan tentang jumlah detik antara dua waktu menjadi lebih sederhana. Setidaknya untuk waktu setelah 2035.

[GN⁺]

Komentar Hacker News

• Saya pernah membaca buku fiksi ilmiah berjudul "A Deepness in the Sky". Di buku itu, penyebutan detik sejak epoch terasa menarik

  • Metode pengukuran waktu Qeng Ho cukup rumit, dan mereka mulai menghitung detik sejak momen manusia pertama kali menginjakkan kaki di bulan
  • Momen awalnya sebenarnya sekitar 15 juta detik setelah itu, dan itu menjadi detik ke-0 pada sistem operasi komputer awal

• Sedang ada upaya untuk menghapus leap second, dan semoga selesai pada 2035

  • Tujuan UTC adalah berada pada selisih sejumlah detik bulat dari TAI sambil mendekati mean solar time
  • Jika tidak ingin melacak MST, maka harus beralih ke TAI, dan jika UTC menyimpang dari MST, leap second historis menjadi tidak bermakna

• "Epoch UTC" modern adalah 1 Januari 1972

  • Pada akhir 1971 ada lompatan tidak teratur sebesar 0.107758 detik TAI, lalu setelah itu laju tick UTC diubah agar tepat sama dengan TAI
  • Unix time untuk 1970 dan 1971 sebenarnya tidak cocok dengan waktu UTC pada periode tersebut

• Setiap kali membaca tentang pengukuran waktu, saya selalu belajar hal baru

  • Saya mengira Unix time adalah cara paling sederhana untuk melacak waktu
  • Saya pikir leap second tidak diterapkan, tetapi sepertinya saya belum memikirkannya cukup jauh

• Baru-baru ini saya mengerjakan kode untuk VAX, atau yang berjalan di atas OpenVMS, dan baru pertama kali melihat epoch 17 November 1858

  • Di dalam kode, itu diabstraksikan sebagai Unix epoch

• Beberapa titik waktu tidak bisa direpresentasikan sebagai timestamp POSIX, dan beberapa timestamp POSIX tidak sesuai dengan waktu nyata

• Saya rasa artikel ini merusak Natal saya

  • Detik seharusnya adalah detik sejak epoch, dan tidak masalah jika itu menyimpang dari hari matahari
  • Konverter detik-epoch seharusnya yang menangani penyesuaian

• Saat menyimpan tanggal di database, saya selalu menyimpannya sebagai waktu Unix epoch, dan informasi zona waktu disimpan terpisah

  • Saya jadi berpikir apakah lebih baik menyimpan timestamp dalam format TAI lalu mengonversinya ke UTC saat diperlukan
  • Zona waktu adalah konsep buatan manusia dan berubah seiring waktu
  • Kita seharusnya berpatokan pada waktu absolut, lalu mengubahnya ke format waktu lokal saat diperlukan

• Sekitar 10 tahun lalu di sebuah konferensi, saya mendengar bahwa Google tidak menggunakan leap second, melainkan menyebarkannya ke detik-detik biasa

  • Google memodifikasi server NTP untuk menyebarkan leap second

• Saya penasaran apakah ada metode pengukuran waktu yang tersinkronisasi dan meningkat secara monoton