Tidak Ada Penambahan Detik Kabisat pada Akhir Desember 2026

• Sesuai IERS Bulletin C 72, tidak ada detik kabisat yang ditambahkan ke UTC pada akhir Desember 2026, sehingga sistem pengukuran dan distribusi waktu tidak perlu menyiapkan penanganan penyisipan khusus
• Selisih antara UTC dan TAI tetap UTC-TAI = -37 s sejak 1 Januari 2017 pukul 00:00 UTC hingga pemberitahuan lebih lanjut
• Keputusan penerapan detik kabisat ditentukan berdasarkan perubahan UT1-TAI, dengan waktu yang memungkinkan pada akhir Juni atau akhir Desember
• Bulletin C setiap 6 bulan mengumumkan langkah waktu (time step) UTC, atau mengonfirmasi tidak adanya langkah waktu pada tanggal berikutnya yang memungkinkan
• Untuk distribusi UTC pada akhir 2026, tidak diperlukan nilai koreksi baru; cukup terus gunakan hubungan UTC-TAI = -37 s yang sudah ada

---

Pemberitahuan UTC dari IERS Bulletin C 72

• IERS menerbitkan Bulletin C 72 di Paris pada 6 Juli 2026, yang menyatakan bahwa detik kabisat tidak akan diterapkan pada akhir Desember 2026
• Pemberitahuan ini ditujukan kepada lembaga yang bertanggung jawab atas pengukuran dan distribusi waktu
• Dua nilai utamanya adalah sebagai berikut
  • Sejak 1 Januari 2017 pukul 00:00 UTC hingga pemberitahuan lebih lanjut, UTC-TAI = -37 s
  • Pada akhir Desember 2026, tidak ada langkah waktu baru pada UTC

Keputusan detik kabisat dan siklus pemberitahuan

• Detik kabisat dapat diterapkan pada UTC bergantung pada perubahan UT1-TAI
• Waktu penerapan yang memungkinkan adalah setiap tahun pada akhir Juni atau akhir Desember
• Bulletin C dikirim setiap 6 bulan
  • Jika ada langkah waktu pada UTC, hal itu akan diumumkan
  • Jika tidak ada langkah waktu pada tanggal berikutnya yang memungkinkan, hal itu akan dikonfirmasi

[GN⁺]

Pendapat di Hacker News

• Saya penasaran apa yang menyebabkan ketidakpastian prediksi ini. Saya kira rotasi dan revolusi Bumi sudah diketahui hingga banyak angka di belakang koma; apakah faktor seperti aktivitas geologis atau cuaca membuat perbedaan kecepatan rotasi sehingga sulit diprediksi?

  • Singkatnya, benar. Cuaca, aktivitas geologis, serta perpindahan air oleh manusia seperti pengurasan akuifer dan pembangunan bendungan, juga mencairnya gletser dan es, semuanya memberi perubahan yang sulit diprediksi pada periode rotasi dan sumbu rotasi Bumi
    Sepingat saya model-model ini berupa polinomial trigonometri berorde rendah, jadi bahkan jika ketidakpastian prediksi dimodelkan secara sempurna, galat pemotongan membuatnya sulit didistribusikan dengan akurasi sangat tinggi, dan karena sudah tertanam di tempat seperti satelit, modelnya juga tidak bisa dibuat rumit sesuka hati
    Sebagai catatan, detik kabisat akan segera dihapus, dan setahu saya akan dihentikan secara bertahap pada 2035. Saya ingat penundaannya karena Rusia perlu waktu untuk memperbarui satelit GLONASS
  • Benar. Ada faktor-faktor itu dan masih banyak lagi. Presisi pengukuran kita jauh lebih baik daripada laju perubahan orde pertama dan kedua tahunan pada panjang hari
    https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... adalah grafik yang paling relevan untuk ini, dan lompatan vertikal menunjukkan detik kabisat. IERS juga punya grafik untuk dimensi rotasi lainnya, tetapi grafik ini enak dilihat
  • Kebetulan saya baru saja mengecek artikel Wikipedia untuk melihat kapan detik kabisat terakhir dimasukkan, dan jawabannya juga ada di sana
    “Kecepatan rotasi Bumi berubah sebagai respons terhadap peristiwa iklim dan geologis, sehingga detik kabisat UTC ditempatkan secara tidak teratur dan tidak dapat diprediksi secara tepat”
    https://en.wikipedia.org/wiki/Leap_second
  • Justru hampir kebalikannya. Rotasi Bumi bisa berubah hingga hitungan detik dari tahun ke tahun, tetapi dalam rentang ratusan tahun variasinya umumnya saling meniadakan
    Karena itu menurut saya upaya menambah atau mengurangi detik kabisat bukan ide yang terlalu bagus. Yang benar-benar peduli pada hal seperti ini pada dasarnya hanya badan antariksa, dan mereka bisa menerapkan nilai koreksi yang mereka inginkan tanpa perlu memengaruhi semua orang
    Dampak praktis drift ini bagi orang biasa kira-kira hanya GPS, dan GPS sudah mengirimkan offset terhadap jamnya sendiri agar penerima bisa melakukan koreksi. Jam GPS berbeda dari UTC maupun TAI
  • Lihat https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co...

• Bukankah ini lebih seperti anti-berita? Samar-samar saya ingat penerapan detik kabisat dihentikan sampai ada pemberitahuan terpisah karena terlalu banyak menimbulkan masalah pada sistem komputasi masa kini
  Saat ini selisihnya 37 detik, dan tak seorang pun perlu khawatir Natal akan bergeser ke sekitar Paskah. Menurut saya masalah ini bisa diwariskan kepada generasi mendatang dengan jauh lebih bertanggung jawab dibanding banyak masalah lainnya
  Pemberitahuan setiap 6 bulan hanya prosedur untuk memenuhi redaksi perjanjian internasional yang asli

  • Belum sampai begitu. Itu masih usulan, dan penghentian resmi kemungkinan sulit terjadi sebelum 2035
    Alasan tidak ada detik kabisat selama beberapa waktu adalah drift antara TAI dan UT1 melambat, dan sebenarnya bergerak sangat pelan ke arah sebaliknya
  • Rasanya tidak masuk akal bahwa periode pemberitahuannya hanya 6 bulan, dan kemungkinan itulah sumber masalahnya
    Kalau waktu meleset sekitar ±60 detik pun tidak ada yang akan menyadarinya, jadi tampaknya lebih mudah dikelola jika memasukkan detik kabisat sewenang-wenang kira-kira sekali per 10 tahun dan mengumumkannya 10 tahun sebelumnya agar semua orang punya waktu menata sistemnya. Enam bulan untuk mengoordinasikan dan menjalankannya di seluruh dunia itu terlalu optimistis

• Kalau dijelaskan seperti kepada anak 5 tahun, saya ingin tahu ini berdampak apa pada timestamp UNIX, terutama untuk hal-hal yang berada dalam mode pemeliharaan atau hampir tidak dikelola
  Pekerjaan saya tidak membutuhkan presisi setingkat ini, tetapi pasti ada bidang yang membutuhkannya

  • Timestamp UNIX sepenuhnya mengabaikan detik kabisat dan memperlakukannya seolah-olah tidak ada
    Jadi saat detik kabisat disisipkan, bisa ada satu detik fisik yang tidak dapat dirujuk dengan timestamp UNIX, dan saat detik kabisat dihapus, bisa ada timestamp UNIX untuk detik yang sebenarnya tidak pernah ada
  • Setiap kali detik kabisat ditambahkan, Google menjalankan jam servernya lebih lambat atau lebih cepat selama periode yang lebih panjang, biasanya beberapa jam, agar perlahan-lahan kembali selaras dengan jam bandul bola sempurna dari platina murni di suatu tempat di NIST: https://developers.google.com/time/smear
  • Hasil time() dan clock_gettime(CLOCK_REALTIME) terpengaruh oleh detik kabisat
    Detik kabisat baru sampai ke sistem melalui NTP. Sayangnya NTP hanya mendistribusikan flag penanda bahwa detik kabisat akan diterapkan, bukan offset itu sendiri. Namun waktu yang didistribusikan itu sendiri sudah terpengaruh oleh detik kabisat, jadi klien NTP tidak harus mengetahuinya
    Sebaliknya, metode sinkronisasi waktu lain seperti GPS dan PTP memakai skala waktu yang tidak terpengaruh detik kabisat dan mendistribusikan offset UTC sebagai informasi tambahan. Menyesuaikan waktu yang diterima di tahap akhir adalah tanggung jawab klien. Kernel memiliki parameter clock_adjtime() untuk detik kabisat
    Pada sistem manual yang memiliki klien NTP, waktu akan berubah saat berjalan untuk menyesuaikan detik kabisat baru. Linux menangani waktu UTC sebagai prioritas, sehingga ini disimpan di perangkat RTC dan tetap ada setelah reboot
    CLOCK_TAI tampaknya seharusnya mengembalikan waktu TAI, tetapi pada distribusi desktop/server Linux umum, ia diperlakukan seperti kelas dua sampai-sampai offset-nya pun tidak disetel dan mengembalikan waktu yang sama dengan CLOCK_REALTIME
    Di dalam /etc ada berkas daftar detik kabisat yang termasuk dalam suatu paket, sehingga pembaruan sistem diperlukan untuk memperbarui berkas ini. Saya tidak berpikir perangkat lunak NTP tradisional memperbarui paket ini secara dinamis. Namun tidak banyak perangkat lunak yang memakai berkas ini
    Jika ada skrip layanan init yang mem-parsing ini untuk menyetel offset UTC kernel, maka sebelum diperbarui CLOCK_TAI sistem bisa terlambat 1 detik dibanding seluruh dunia. Namun sejauh yang saya tahu, ini tidak berdampak apa pun pada waktu UTC di Linux

• Frasa “kepada lembaga-lembaga yang bertanggung jawab atas pengukuran dan distribusi waktu” adalah preambule yang benar-benar legendaris

  • Yang lebih bagus lagi, nama organisasinya adalah International Earth Rotation Service
  • Selama bertahun-tahun, jabatan kepemimpinan di USNO yang mengoordinasikan berbagai keluaran waktu presisi adalah “Director of the Directorate of Time”
  • Ini seperti ungkapan yang mungkin muncul di novel Douglas Adams
  • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
    Jabatannya saja terdengar seperti fiksi ilmiah

• Jika offset UTC-TAI tetap -37 detik, itu berarti offset UTC-GPS juga tetap -18 detik
  TAI dan GPS memiliki offset tetap 19 detik di antara kedua sistem tersebut

• Saya penasaran apa yang terjadi pada sistem seperti Spanner dalam situasi seperti ini
  Apakah ini jadi masalah besar, atau bukan apa-apa?

  • Ini masalah besar. Cara paling umum untuk menanganinya disebut smearing, yaitu menyesuaikan panjang setiap detik selama 24 jam sebelum “detik kabisat”
    Pada sistem yang membutuhkan jaminan urutan ketat, ini bekerja karena tiap perangkat tetap tersinkron dengan jam global, dan hanya panjang siklus jamnya yang berubah sangat sedikit. Kalau tidak salah, ini memang ada di paper Spanner asli
    Beberapa sistem yang jarang ditemui memakai detik osilator monoton dan mengabaikan detik rotasi Bumi, tetapi jika suatu saat harus dikonversi ke waktu nyata, bencananya akan terakumulasi seiring waktu, dan secara umum dianggap bukan ide bagus
  • Detik kabisat tidak ditambahkan menurut jadwal rutin seperti hari kabisat, melainkan bergantung pada pengukuran fisik Bumi
    Jadi sistem dengan keandalan tinggi yang memiliki manajemen waktu komprehensif sepertinya tidak akan terlalu terguncang oleh keputusan semacam ini

• Dengan adanya Temporal API, apakah browser atau Node.js dan sejenisnya dapat menangani waktu dengan benar dalam operasi di sekitar titik waktu itu? Atau perlu pembaruan agar perhitungannya tidak kacau?

  • Temporal API tampaknya berbasis timestamp Unix/POSIX, yang mengabaikan detik kabisat. Dalam waktu Unix, satu hari selalu 86400 “detik”
    Karena itu, perhitungan kalender UTC untuk masa lalu dan masa depan mudah dilakukan tanpa database, dan tidak harus menangani pecahan detik. Detik kabisat ditangani oleh sistem operasi dengan mengulang atau melewati 1 detik, atau dengan menyesuaikan panjang detik selama periode tertentu sebelum dan sesudah detik kabisat
    Sebagian besar API tanggal-waktu pada dasarnya dirancang untuk mendukung operasi kalender dan jam dinding bagi fungsi bisnis. Jika membutuhkan detik SI untuk tujuan ilmiah, Anda harus memakai API dan kapabilitas terpisah yang menyediakan serta menjamin semantik yang diperlukan hingga level hardware
    Demikian pula, jika membutuhkan timer untuk fungsi software seperti thread sleep, Anda harus memakai antarmuka khusus seperti jam monoton. Situasi ini tidak banyak berubah meski detik kabisat dihapus secara bertahap. Dengan atau tanpa penyesuaian detik kabisat, misalnya, algoritma mutex yang bergantung pada timestamp Unix dulu salah dan tetap akan salah

• Dengarkan ide saya. Pasang mesin jet di ekuator, putar 180 derajat, lalu kita bisa mendapatkan atau kehilangan waktu. Lalu sambungkan itu ke tombol snooze saya

  • Bukankah lebih mudah kalau Superman terbang mengelilingi Bumi sangat cepat berkali-kali? Dengan begitu tidak perlu khawatir soal perawatan mesin
  • Dalam praktiknya, memindahkan air dalam jumlah yang sangat besar mungkin bisa memberi dampak terukur. Misalnya seperti menguras akuifer California Central Valley
  • Masalahnya adalah masyarakat masa depan akan mengambil kembali mesin-mesin itu untuk wahana antarbintang. Masalah ini dibahas dalam seri buku Larry Niven
  • Sepertinya kalau kita semua lompat bersamaan juga bisa. Yang dibutuhkan cuma 1–2 detik, kan?
  • Melihat sudah cukup lama tidak perlu memasukkan detik kabisat, sepertinya cara ini berhasil

• Tertulis “Perbedaan antara UTC dan TAI adalah UTC-TAI = -37s sejak 1 Januari 2017 pukul 0 UTC hingga pemberitahuan lebih lanjut”
  Apakah ini berarti jam atom tertinggal 37 detik dari jam matahari? Saya juga tidak paham kenapa 2017 disebut

  • Justru hampir kebalikannya
    Satu hari UTC didefinisikan persis 86400 detik SI. Namun rata-rata hari matahari sebenarnya beberapa milidetik lebih panjang. Karena ketidakteraturan rotasi Bumi, selisihnya tidak konstan, tetapi rata-rata selisihnya diperkirakan perlahan bertambah seiring waktu. Detik SI dihitung dengan jam atom, jadi UTC berganti hari setiap 86400 detik jam atom
    Sebaliknya, jam matahari yang berganti hari setiap kali matahari rata-rata mencapai tengah hari berganti hari beberapa milidetik lebih lambat daripada UTC. Matahari nyata bergerak melintasi langit dengan kecepatan berbeda sepanjang tahun, jadi yang harus dipakai adalah matahari rata-rata
    Dengan kata lain, setiap periode yang oleh jam matahari disebut tepat 86400 detik sebenarnya beberapa milidetik lebih panjang menurut jam atom
    Hal ini menumpuk setiap hari, dan ketika hampir mencapai 1 detik, detik kabisat disisipkan ke UTC sehingga hari itu menjadi 86401 detik, bukan 86400 detik. Sebab UTC bukan sekadar menghitung waktu jam atom; karena banyak aktivitas manusia terkait dengan posisi matahari di langit, UTC juga harus disinkronkan dengan matahari
    Manusia mendefinisikan “sinkron dengan matahari” sebagai “dalam 1 detik dari matahari rata-rata”. Artinya, kita ingin tengah hari UTC berada dalam 1 detik dari tengah hari matahari rata-rata di meridian utama
    Jadi 37 detik berarti seberapa jauh tengah hari matahari rata-rata akan tertinggal dari tengah hari UTC jika detik kabisat tidak digunakan. Saat tengah hari UTC, matahari rata-rata masih akan kurang 37 detik untuk melewati meridian utama di langit
  • Menurut Wikipedia, Desember 2016 adalah terakhir kali detik kabisat disisipkan: https://en.wikipedia.org/wiki/Leap_second
  • Penyebutan 2017 mungkin karena offset terakhir kali berubah saat itu. Jadi -37 detik tetap berlaku sejak saat itu