`Australia/Lord_Howe` adalah zona waktu paling aneh

• Zona waktu itu rumit, tetapi karena komputer harus mengimplementasikannya, keanehannya hanya berada dalam cakupan yang terbatas.
  • Asia/Kathmandu memiliki offset yang tidak biasa dari UTC.
  • Africa/Casablanca di-hardcode karena tidak cocok dengan model zona waktu dengan baik.
  • America/Nuuk memulai waktu musim panas dari -01:00.
  • Africa/Cairo dan America/Santiago memulai waktu musim panas pada pukul 24, bukan 0.
  • Australia/Lord_Howe memiliki aturan waktu musim panas yang paling aneh.

PGXIIREAM: Paus Gregorius XIII mengendalikan segalanya

• Sebagian besar dunia menggunakan sistem waktu yang berbasis kalender Gregorian.
• Kalender Gregorian sangat berguna untuk menjaga posisi matahari tetap konsisten sepanjang tahun.
• UTC adalah formalisasi modern resmi dari kalender Gregorian, dan seluruh dunia menetapkan waktu berdasarkan ini.

Detik kabisat tidak penting

• Rotasi bumi melambat, sehingga detik kabisat ditambahkan untuk mengoreksinya.
• Detik kabisat bisa diabaikan karena bahasa pemrograman tidak merepresentasikan detik ke-61.
• Penyedia cloud menyelesaikan masalah ini dengan memperlambat jam selama detik kabisat.

Zona waktu yang aneh

Asia/Kathmandu memiliki offset yang tidak biasa

• Nepal berada 5 jam 45 menit lebih cepat dari UTC.
• Komputer dapat mengetahui informasi ini melalui basis data zona waktu IANA.

String seperti PDT atau CET tidak bermakna

• Pengidentifikasi zona waktu bisa ambigu, dan banyak zona waktu berbagi pengidentifikasi yang sama.

Bagaimana zona waktu dengan waktu musim panas direpresentasikan?

• Aturan transisi waktu musim panas itu rumit, dan komputer menghitung waktu lokal berdasarkan aturan tersebut.

Africa/Casablanca dan Asia/Gaza mengikuti bulan, tetapi zona waktu mengikuti matahari

• Maroko dan Gaza menyesuaikan waktu musim panas berdasarkan Ramadan, dan ini di-hardcode.

America/Nuuk beralih ke waktu musim panas pada pukul -1

• Greenland memulai waktu musim panas pada saat yang sama dengan Eropa, tetapi dalam waktu lokal dimulai pada pukul -1.

America/Santiago dan Africa/Cairo beralih pada pukul 24

• Zona waktu ini beralih ke waktu musim panas pada pukul 24, yang berarti melewati ke hari berikutnya.

Australia/Lord_Howe memiliki transisi waktu musim panas yang paling aneh

• Pulau Lord Howe memiliki transisi waktu musim panas selama 30 menit.

Ringkasan GN⁺

• Zona waktu itu rumit, tetapi karena komputer harus mengimplementasikannya, keanehannya hanya berada dalam cakupan yang terbatas.
• Australia/Lord_Howe adalah zona waktu paling unik karena transisi waktu musim panasnya selama 30 menit.
• Artikel ini berguna untuk memahami kompleksitas zona waktu dan bisa menarik bagi para programmer.
• Proyek dengan fungsi serupa termasuk tzdb.

[GN⁺]

Komentar Hacker News

• Bagian paling menarik dari basis data tz adalah adanya perkiraan waktu Big Bang, dan transisi zona waktu yang terjadi sebelum Big Bang memang tidak dihitung
  Pesan commit di https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... juga kurang lebih berbunyi “jangan menghasilkan timestamp sebelum Big Bang karena secara fisika meragukan”, lalu tak lama kemudian commit terpisah juga melarang leap second sebelum Big Bang

  • Dulu ada halaman manual panjang yang membahas makna tanggal masa lalu di Linux/Unix date
    Ada contoh sekitar abad ke-15, dengan cerita seperti seorang raja menyukai minggu/bulan tertentu lalu memerintahkan agar itu diulang, atau raja lain membenci minggu tertentu lalu menghapusnya dari kalender. Itu bacaan yang cukup membuka wawasan, tetapi sekarang tidak bisa saya temukan
  • Ini terlihat seperti keputusan yang cukup praktis. Cara bagus untuk mencegah sejak awal perdebatan tak berguna semacam perdebatan malaikat di ujung jarum di antara para kontributor
    Dengan kata lain, kesimpulannya adalah “momen sebelum Big Bang berada di luar cakupan library ini, jadi jika suatu algoritme hanya menghasilkan nilai salah sebelum Big Bang, algoritme itu dapat diterima dan tidak perlu diperbaiki/diganti”
  • Bagian itu memang keren, tetapi secara terpisah saya agak skeptis terhadap upaya tzdb untuk menangani hingga sebelum Unix epoch
    Manfaatnya dibandingkan bug di bagian itu tampak tidak besar, dan sebagian besar kompleksitas berantakan tzdb ada di zic. Kadang saya merasa akan lebih baik jika zic bukan artefak yang bisa dijadikan dependensi oleh orang lain
  • Ini easter egg yang menarik di basis data TZ. Baru pertama kali mendengarnya, tetapi saya bertanya-tanya seberapa sering orang perlu menghitung data zona waktu setua itu
    Semoga zona waktu itu sendiri menghilang sebelum teori zona waktu menjadi usang

• Menurut saya zona waktu paling aneh adalah Africa/Addis_Ababa. Justru penduduk lokal Etiopia tidak mengikuti cara itu
  Di sana, waktu digeser 6 jam sehingga siklus AM dimulai saat fajar, yaitu pukul 06.00, dan siklus PM dimulai saat senja, yaitu pukul 18.00
  https://en.wikipedia.org/wiki/Time_in_Ethiopia

  • Ini umum di seluruh Afrika Timur, termasuk Kenya. Malam berakhir pukul 06.00, dan pukul 07.00 menjadi jam pertama hari itu, yaitu saa moja
    Demikian pula, hari berakhir pukul 18.00, thenashara. Secara intuitif ini jauh lebih masuk akal daripada jam dunia berbahasa Inggris, dan karena tertanam dalam bahasa, kebingungan waktu pun jarang terjadi
  • Perhitungan waktu di Etiopia secara umum memang unik
    https://en.wikipedia.org/wiki/Ethiopian_calendar
    Kalender Etiopia terdiri dari 12 bulan yang masing-masing 30 hari, serta 5 atau 6 hari epagomenal yang membentuk bulan ke-13
  • Ini sangat mirip dengan cara orang Romawi memahami waktu. Saya penasaran apakah ini jejak lama dari masa ketika Afrika Utara terdiri dari beberapa provinsi Romawi
    https://en.wikipedia.org/wiki/Roman_timekeeping
  • Untuk negara di dekat khatulistiwa, cara mendefinisikan siklus harian seperti itu tidak terlalu tidak masuk akal
  • Jepang juga memakai cara serupa dalam konteks fasilitas yang tutup setelah tengah malam: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...
    Dunia berbahasa Inggris dulu juga mengganti tahun pada 25 Maret: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
    Keduanya secara teknis bukan objek yang bisa ditangani tzdb. tzdb menangani waktu sipil (civil time), bukan kalender atau metode perhitungan lain

• Keanehan Asia/Jerusalem muncul karena daylight saving time sangat terkait dengan isu pemisahan agama dan negara. Orang-orang religius ingin hari kerja lebih nyaman disesuaikan dengan hari raya yang dimulai saat matahari terbenam
  Karena itu, selama puluhan tahun hingga pertengahan 2000-an, daylight saving time adalah hasil negosiasi tahunan antara partai religius dan partai sekuler, dan sering baru diputuskan tepat sebelum tanggal transisi sehingga kerap menimbulkan masalah
  Masih ada pengecualian agar daylight saving time tidak berakhir pada Rosh HaShanah, sehingga aturan masa depannya tampak rumit

  • Manfaat daylight saving time terbatas, dan terutama untuk negara yang relatif berada di selatan, saya penasaran mengapa tidak dihapus sepenuhnya
    Kalau EU akhirnya berhasil menghapusnya, mungkin mereka akan ikut
  • Itu karena Paskah Yahudi. Jamuan perayaan besar yang disebut Seder berlangsung hingga setelah tengah malam, dan juga merupakan acara yang sangat penting bagi anak-anak
    Jadi mereka tidak ingin daylight saving time membuat acara yang sudah berakhir larut menjadi lebih larut lagi. Selain itu, pada hari puasa Yom Kippur, mereka ingin puasa berakhir 1 jam lebih awal. Karena harus menyesuaikan dengan tanggal-tanggal ini, periode daylight saving time menjadi terlalu pendek sehingga perlu dinegosiasikan
  • Tidak ada lagi pengecualian. IDT diperpanjang hingga hari Minggu terakhir bulan Oktober pada 2013

• Pernyataan bahwa “bahasa pemrograman tidak bisa merepresentasikan menit berdurasi 61 detik” sebenarnya tidak benar. Seseorang sudah menyebut bahwa Raku mendukung detik kabisat, dan itu mungkin sebagian salah saya
  Karena DateTime.pm, pustaka tanggal/waktu paling populer di Perl 5, mendukung detik kabisat, dan saya menerapkan dukungan itu saat membuat DateTime.pm
  Kalau dipikir-pikir, itu hampir pasti sebuah kesalahan. Hampir tidak ada yang peduli dengan detik kabisat, dan itu hanya menimbulkan kebingungan aneh seperti “kenapa menambahkan 60 detik kadang berbeda dari menambahkan 1 menit?”
  Terutama karena kami mencoba memvalidasi apakah second => 60 valid, kodenya menjadi jauh lebih rumit. Konstruktor menerima komponen waktu dan zona waktu arbitrer, jadi untuk memeriksa tabel detik kabisat harus dikonversi ke UTC, tetapi konversi itu sendiri, karena alasan historis, menjadi terkait dengan nilai-nilai yang mencakup detik kabisat
  Hasilnya kekacauan besar demi manfaat yang sangat kecil, dan karena pustaka tanggal/waktu standar Raku tampaknya banyak meminjam dari DateTime.pm milik Perl 5, saya rasa ia juga mewarisi sebagian keputusan desain buruk yang sama

  • Bagus bahwa itu diimplementasikan begitu dan belakangan kita bisa meninjau solusi yang lebih elegan
    Saya penasaran seperti apa proses berpikirnya pada awalnya. Apakah terlalu tenggelam dalam masalahnya? Kalau terlalu dekat dengan masalah dan terlalu lama fokus, kesenangan memperbaikinya sebelum rusak sering membuat hal seperti ini terjadi
  • Di Raku ada kelas Instant
    Didefinisikan kurang lebih sebagai “Instant adalah momen tertentu yang diukur dalam detik atomik beserta bagian pecahannya, dan tidak terikat pada epoch mana pun maupun aware terhadapnya”

• Awal tahun ini saya harus menulis fungsi untuk menemukan waktu lokal saat ini ketika diberi alamat di AS. Cara naifnya adalah memetakan negara bagian secara statis ke zona waktu, tetapi ada cukup banyak pengecualian yang membuat itu tidak bisa dilakukan
  Dalam aplikasi tersebut, biaya dan kecepatan penting, jadi kami membeli CSV seharga beberapa dolar yang memetakan semua ZIP code AS ke offset UTC, apakah mematuhi daylight saving time, dan sebagainya
  Karena pytz menerima nama zona waktu IANA, pada akhirnya kami harus memetakan informasi offset dan daylight saving time secara manual ke zona waktu tertentu, dan karena wilayah luar negeri AS serta pangkalan militer, kami juga membutuhkan semantik aneh seperti zona waktu Etc
  [1] https://en.wikipedia.org/wiki/Tz_database#Area

  • Tingkat negara bagian benar-benar resolusinya salah. Zona waktu AS mengikuti batas county dan reservasi penduduk asli
    ZIP code mungkin juga cukup, tetapi harus hati-hati. Jika jumlah alamat tidak terlalu banyak, cara yang lebih tangguh adalah melakukan reverse geocoding lalu memakai pustaka yang memperoleh pengenal IANA dari poligon batas zona waktu
    https://github.com/RomanIakovlev/timeshape dikelola oleh mantan rekan kerja saya, dan kami bisa membuka sebagian pekerjaan internal kami sebagai open source
  • Pada 1985, ketika saya masih insinyur muda yang baru lulus kuliah, saya ditugasi menggabungkan data telemetri yang direkam di pita magnetik dari beberapa situs radar di AS
    Satu atau dua sistem memberi timestamp data dalam waktu lokal, sedangkan sisanya memakai UTC. Untuk membuat algoritme yang menangani daylight saving time, saya membeli Farmers' Almanac lama, tetapi setelah membaca aturannya saya putus asa
    Di kalender ada aturan nominal untuk transisi, tetapi ada catatan kaki bahwa aturan itu telah disesuaikan dari tahun ke tahun karena campur tangan Kongres, dan akan terus begitu. Saya berkata kepada atasan saya, “kalau saya bisa menulis algoritme untuk memprediksi pemungutan suara Kongres di masa depan, saya sudah menjadi miliarder dan berhenti dari pekerjaan insinyur ini”
    Pada akhirnya sepertinya saya mengodekan transisi terbaru yang diketahui dan aturan nominal untuk masa depan. Itu sebelum semua orang terhubung ke jaringan, dan kodenya berjalan di komputer mandiri seperti VAX, jadi tidak banyak pilihan lain
    Menggabungkan tiga sumber data pelacakan yang masing-masing punya status validitas dan penurunan kualitas pengukuran juga mimpi buruk, tetapi masih lebih mudah daripada memprediksi tindakan Kongres di masa depan
  • Pendekatan yang baik adalah memetakan ZIP code ke zona waktu bernama seperti US/Eastern. Setelah itu, jika butuh offset UTC, terapkan zona waktu itu pada tanggal tersebut dengan pytz untuk mendapatkan offset-nya
    Zona waktu bernama itu istimewa karena bersifat tetap. Zona waktu berbasis offset UTC seperti -05:00 atau singkatan seperti EST tidak tetap untuk lokasi tertentu seiring waktu karena daylight saving time
    Jika Anda menanyakan zona waktu kepada seseorang sambil memberi offset atau singkatan sebagai pilihan, semua orang akan bingung
  • Awal tahun ini saya melakukan hal serupa: memakai layanan geolokasi untuk mengubah alamat menjadi lintang/bujur, lalu dari lintang/bujur mendapatkan zona waktu. Untuk negara bagian dengan satu zona waktu, saya menyediakan jalur pintas
    Untuk konversi lintang/bujur → zona waktu, saya memakai pustaka Python ini: https://github.com/jannikmi/timezonefinder
    Sumber datanya juga tampak seperti sumber yang cukup berkualitas: https://github.com/evansiroky/timezone-boundary-builder/rele...
  • Pengenal Etc benar-benar harus hati-hati. Terutama jika Anda berniat menampilkan semua pengenal apa adanya kepada pengguna
    Di file tersebut ada komentar: “POSIX menganggap arah barat Greenwich sebagai positif, tetapi banyak orang mengharapkan arah timur Greenwich sebagai positif. Misalnya TZ='Etc/GMT+4' memakai singkatan -04 dan berarti 4 jam lebih lambat dari UT, yaitu sebelah barat Greenwich, tetapi banyak orang mengira itu sebelah timur yang 4 jam lebih cepat dari UT”

• Zona waktu Palestina juga cukup aneh
  https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
  Mereka punya daylight saving time, tetapi tanggalnya tidak tetap; pemerintah mengumumkan waktu mulai dan berakhirnya setiap tahun. Kadang diumumkan kurang dari seminggu sebelumnya, sehingga mau tidak mau menimbulkan berbagai masalah menarik

  • Muncul fenomena dua orang yang tinggal di lokasi fisik yang sama mengikuti waktu saat ini yang berbeda berdasarkan identitas etnis dan geopolitik mereka
    Tanggal mulai dan berakhir daylight saving time Israel dan Palestina tidak selalu sama
  • Saya tidak tahu apakah sekarang masih begitu, tetapi Brasil dulu juga seperti itu. Karena itu saya pernah hampir ketinggalan pesawat
  • Ini memang disebutkan dalam artikel aslinya, dan terkait dengan Ramadan
  • Bahkan tanpa membahas politik terlalu dalam, saya sulit memahami mengapa upaya diprioritaskan untuk daylight saving time. Sepertinya ada jauh lebih banyak hal lain yang perlu dikhawatirkan

• Menurut saya, menyebut daylight saving time yang selisihnya 30 menit, bukan 1 jam, sebagai “zona waktu paling aneh” menetapkan standar yang terlalu rendah
  Hampir semua yang lain lebih aneh. Antarctica/Troll jelas terdengar lebih aneh, dan zona waktu Maroko serta Gaza punya aturan yang setidaknya berbeda jenisnya, sampai-sampai tidak bisa direpresentasikan dengan sistem yang ada. Zona-zona waktu yang masuk daftar larangan Apple, yang beralih sehari sebelum tanggal tertentu, juga cukup aneh untuk merusak sesuatu
  Soal detik kabisat, saya setuju. Itu lebih merupakan pengetahuan trivia daripada pengetahuan berguna yang perlu diketahui programmer. Komputer menangani detik kabisat dengan smearing, dan bahkan tidak tahu kapan itu terjadi. Kita boleh saja melupakannya sepenuhnya
  Namun, pernah ada masa ketika negara-negara beralih dari cara mengabaikan detik kabisat ke cara memperhitungkannya, jadi perubahan Australia dari GMT+x ke UTC+x beberapa dekade lalu adalah transisi dari mengabaikan detik kabisat menjadi menyertakannya. Fakta bahwa hal ini hampir secara universal diabaikan mungkin justru hal yang baik

  • Secara umum saya setuju bahwa detik kabisat adalah trivia
    Namun selalu agak lucu ketika sebuah organisasi besar mengatakan “server kami memiliki akurasi waktu di bawah milidetik berkat sinkronisasi GPS dan kartu jam atom rubidium PCIe yang kami kembangkan sendiri”, tetapi pada saat yang sama juga mengatakan “detik kabisat kami smear sepanjang satu hari, jadi secara praktik tidak masalah kalau waktu server meleset ±0,5 detik”
    [1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
    [2] https://engineering.fb.com/2020/03/18/production-engineering...
  • Tanggal Ramadan bukan nilai yang sudah diketahui dengan pasti. Sebab, itu didasarkan pada apakah bulan benar-benar bisa terlihat di wilayah tertentu di Bumi
    Misalnya, jika langit sangat berawan, bulan tidak akan terlihat di mana pun posisinya. Ini menimbulkan masalah saat mengimplementasikan kalender untuk penyelenggaraan negara
    Banyak negara yang secara resmi mengadopsi kalender Islam menggunakan perkiraan tanggal yang dihitung sebelumnya berdasarkan visibilitas yang diperkirakan dari lokasi tertentu. Jadi kalender Islam sebenarnya bukan satu, melainkan lebih seperti dua: kalender Islam observasional dan kalender prediktif, dan keduanya bergantung pada lokasi tempat observasi aktual atau prediksi dilakukan
    Saya tidak tahu bagaimana Maroko atau Gaza melakukannya
  • Antarctica/Troll tidak seaneh itu. Dalam praktiknya, mereka memakai waktu Cape Town selama musim panas yang singkat, dan waktu Norwegia pada sisa tahun
    Hanya saja waktu Norwegia kebetulan menggunakan daylight saving time
  • Detik kabisat umumnya memang trivia, tetapi menjadi sangat penting dalam aplikasi yang mengharuskan beberapa pihak menyepakati urutan waktu secara tepat. Contoh utamanya adalah transaksi keuangan
    Banyak pasar tutup selama detik kabisat, dan banyak bank masih menghentikan semua transaksi saat perubahan waktu lokal untuk mengurangi risiko kesalahan
    Bahkan pada aplikasi yang tidak terlalu peduli, ada begitu banyak bug terkait detik kabisat yang mengejutkan, dan ada alasan bagus mengapa CGPM memutuskan menghapus detik kabisat
    https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
  • Saya datang mencari Troll. Setahu saya itu satu-satunya tempat yang punya daylight saving time musim dingin, dan namanya memberi poin tambahan juga

• Tulisan bagus tentang akrobatika perangkat lunak zona waktu. Benar-benar cukup fleksibel
  Kalau semuanya berupa offset terbatas yang terotomatisasi, kebijakan daylight saving tidak harus selalu disesuaikan 60 menit
  Mungkinkah suatu negara memutuskan memakai offset yang berubah secara kontinu sepanjang tahun? Tabel lookup offset akan menjadi jauh lebih panjang, tetapi dengan cara ini daylight saving time mungkin bisa “dipecahkan”. Karena terus disesuaikan sedikit demi sedikit, orang tidak akan menyadarinya, seperti detik kabisat
  Orang-orang yang bergantung pada jam analog mungkin tidak lagi selalu menyesuaikannya ke arah yang sama

  • Sejak sinkronisasi jam pada perangkat elektronik menjadi umum, saya telah mengusulkan kepada siapa pun yang mau mendengarkan agar jam dimajukan 10 menit pada hari Minggu pertama setiap bulan selama 6 bulan, lalu dimundurkan 10 menit pada hari Minggu pertama setiap bulan selama 6 bulan sisanya
    Perubahan 10 menit sebulan sekali jauh lebih mudah beradaptasi, hampir tidak terasa, dan kalau terlewat pun tidak sebesar masalah salah 1 jam
  • Kalau menuju ke arah itu, kesimpulan logisnya adalah menghapus konsep zona waktu itu sendiri dan kembali ke waktu matahari lokal
  • Anda mengabaikan cara termudah untuk “memecahkan” daylight saving time
    Hentikan saja daylight saving time. Secara pribadi saya lebih memilih waktu standar permanen daripada daylight saving time permanen, tetapi saya bisa menerima apa pun asalkan kita berhenti mengubah jam dua kali setahun
  • India memakai UTC+5:30 dan tidak menerapkan daylight saving time, jadi menarik saat berinteraksi dengan dunia
    Tentu saja Tiongkok terkenal sangat luas tetapi hanya memiliki satu zona waktu, sehingga menciptakan situasi menarik baik secara internal maupun eksternal
  • Secara teori ini bisa diekspresikan dengan tzdb. Tentu saja akan menimbulkan masalah
    Asumsi sangat penting yang tidak terlihat jelas dalam format data TZif adalah bahwa saat beralih dari waktu lokal ke waktu UTC, kemungkinan yang ada paling banyak hanya dua
    Banyak perangkat lunak bergantung pada asumsi ini; misalnya java.time.LocalDateTime memiliki withLaterOffsetAtOverlap(): https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
    Ini secara implisit mengasumsikan bahwa ketika makna pukul 2:30 pagi ambigu, hanya ada dua solusi yang mungkin, yaitu sebelum dan sesudah daylight saving time. Jika suatu zona waktu memutar mundur jam sekali pada pukul 2 pagi lalu memutarnya mundur lagi pada pukul 2:15, sehingga menghasilkan tiga solusi atau lebih, banyak hal tidak akan mampu mengekspresikannya

• Hal yang saya sukai dari basis data tz adalah bahwa secara teknis ia adalah diff dari diff
  Karena ia menyimpan bagaimana selisih setiap zona waktu terhadap UTC berubah secara historis, itu bisa dianggap sebagai diff^2. Namun basis data tz juga menerima pembaruan, jadi commit-nya adalah diff dari diff dari diff, yaitu diff^3
  Bisa dilanjutkan lagi. Ada changelog, dan changelog itu disimpan di git, jadi commit terhadap changelog tz adalah perubahan terhadap daftar perubahan dari daftar perubahan dari daftar perubahan terhadap UTC, yaitu diff^4

  • Anda melewatkan bahwa UTC, dan lebih luas lagi pengukuran waktu itu sendiri, juga merupakan diff
  • Diff dari diff itu hanya dua diff. Bukan perkalian diff

• Menurut saya framing kuncinya adalah bahwa hampir semua tanggal/waktu sebenarnya merupakan sekumpulan aturan pencocokan yang sedang dipantau
  Kita bisa menebak berapa detik lagi sampai suatu kecocokan terpicu, tetapi kita tidak bisa sepenuhnya yakin sebelum itu benar-benar terjadi, dan dalam beberapa kasus mungkin tidak pernah terjadi secara persis
  Separuh berikutnya adalah mengubah tebakan delta “sepertinya akan terjadi X detik dari sekarang” kembali menjadi “pada saat itu jam zona waktu Anda sepertinya akan menampilkan Y”
  Jangan lupa terus melacak zona waktu mana yang mengendalikan event, dan zona waktu mana yang dipakai untuk menampilkannya
  [1] Estimasi UTC bisa meleset maju atau mundur sebesar detik kabisat. TAI lebih aman, tetapi itu bisa berubah jika seseorang menemukan sesuatu yang menarik dan baru yang mengubah perilaku atom sesium
  [0] Misalnya, sebuah negara bisa saja hilang sehingga zona waktunya ikut lenyap. Atau jam bisa melompat dari 1:00 ke 2:00 sehingga rentang 1:30–2:00 tidak pernah terjadi secara persis karena 1 jam yang terlewat