Di mana Waktu Unix / Waktu Resmi Diukur? [Tutup]

20

Menyangkal hal:

Saya baru saja melihat daftar situs StackExchange selama sekitar 20 menit mencoba mencari tahu di mana memposting ini. Jika Anda tahu ada situs yang lebih cocok, silakan pindahkan pertanyaan ini ke sana. Saya memposting ini di sini karena waktu unix membuat saya berpikir.

Jadi seperti yang kita semua tahu, ada waktu unix dan ada UTC. Waktu Unix terus berdetak, menghitung detik - satu detik per detik -, sedangkan UTC mencoba untuk menjaga waktu dalam format yang dapat dibaca manusia yang kami gunakan selaras dengan fase Bumi dalam rotasi. Untuk melakukan ini, sisipan UTC melompat detik dari waktu ke waktu.

Karena waktu relatif terhadap gaya gravitasi, objek yang mengalami waktu terpapar oleh, jenis percepatan lain, dan kecepatan relatif, ini mengarah pada 2 pertanyaan. Mari kita melupakan yang sederhana dulu: Di mana waktu unix diukur? Jika Alice dan Bob mulai menyetujui waktu saat ini adalah 1467932496.42732894722748 ketika mereka berada di tempat yang sama (yang kedua tentu saja didefinisikan sebagai 9'192'631'770 siklus radiasi sesuai dengan transisi antara dua tingkat energi cesium-133 atom saat istirahat dan pada 0 K), mengalami paradoks kembar karena Alice hidup di permukaan laut dan Bob tinggal tinggi di pegunungan atau Alice tinggal di kutub utara dan Bob tinggal di khatulistiwa, mereka tidak akan setuju lagi. Jadi bagaimana waktu unix didefinisikan secara tepat?

Anda mungkin tidak akan melihat masalah dengan UTC pada awalnya karena pasti semua orang dapat menyetujui kapan bumi menyelesaikan orbit (ini tentu saja mengabaikan pergerakan lempeng benua, tetapi saya pikir kita dapat mengetahui yang mana dengan cukup baik karena dengan GPS dimungkinkan untuk mengukur pergerakan mereka. sangat tepat dan kita dapat mengasumsikan mereka berada pada posisi yang ditentukan dalam model kita dan tidak bergerak ketika lempeng benua bergeser), tidak peduli apakah mereka berada di gunung, di permukaan laut, di khatulistiwa, atau di kutub utara. Mungkin ada beberapa perbedaan waktu tetapi tidak menumpuk.

Tetapi yang kedua didefinisikan sebagai 9'192'631'770 siklus radiasi yang sesuai dengan transisi antara dua tingkat energi atom cesium-133 saat istirahat dan pada 0 K dan atom cesium-133 tidak peduli tentang orbit bumi. Jadi UTC memutuskan di mana memasukkan lompatan kedua tetapi harus ada pergeseran terukur atau yang diperkirakan antara fase orbit bumi dan waktu yang diukur di suatu tempat oleh jam atom. Di mana tempat itu?

timestamps time UTF-8
sumber
5
"Waktu Unix terus berdetak, menghitung detik - satu detik per detik" - sebenarnya, tidak. Segalanya akan lebih sederhana jika itu terjadi.
hobbs
3
Pertanyaan yang menurut saya ingin Anda tanyakan adalah pada topik Fisika - tetapi ini adalah pertanyaan tentang standar waktu, seperti UTC, dan tidak ada hubungannya dengan waktu UNIX. Lihat juga ini dan ini dan pertanyaan terkait lainnya.
David Z
7
Saya memilih untuk menutup pertanyaan ini sebagai di luar topik karena ini tentang fisika, politik, dan standar temporal, tetapi bukan Unix.
Michael Homer
3
Ada mungkin on-topik pertanyaan di suatu tempat di daerah ini yang Anda bisa bertanya, tapi saya tidak berpikir ini itu. Itu hanya memiliki "... dan bagaimana dengan Unix?" sesekali melemparkan ke pertanyaan yang tidak terkait, seperti yang diilustrasikan jawabannya.
Michael Homer
1
Terkait: Unix Seconds, TAI (SI) Seconds, Leap Seconds, dan Real-World Code .
Scott

Jawaban:

30

Pertanyaan utama Anda tidak memiliki jawaban nyata; Waktu unix bukanlah skala waktu nyata, dan tidak "diukur" di mana pun. Ini adalah representasi UTC, meskipun yang buruk karena ada saat-saat di UTC yang tidak dapat diwakilinya. Waktu Unix menegaskan ada 86.400 detik setiap hari, tetapi UTC menyimpang dari itu karena lompatan detik.

Mengenai pertanyaan Anda yang lebih luas, ada empat rentang waktu penting yang menarik:

  1. UT1 (Waktu Universal), yang dihitung oleh observatorium di seluruh dunia yang mengukur rotasi bumi sehubungan dengan bintang-bintang tetap. Dengan pengamatan ini dan sedikit matematika, kita mendapatkan versi yang lebih modern dari Greenwich Mean Time, yang didasarkan pada momen siang matahari di Royal Observatory di Greenwich. Waktu Universal dihitung oleh Organisasi yang disebut IERS (Layanan Rotasi Bumi dan Sistem Referensi Internasional, sebelumnya disebut Layanan Rotasi Bumi Internasional).

  2. TAI (International Atomic Time), yang disimpan oleh ratusan jam atom di seluruh dunia, dikelola oleh badan standar nasional dan semacamnya. Penjaga jam yang berkontribusi pada TAI menggunakan teknik transfer waktu untuk mengarahkan jam mereka ke satu sama lain, membatalkan kesalahan kecil dari masing-masing jam dan membuat waktu ensemble; ansambel itu adalah TAI, diterbitkan oleh International Bureau of Weights and Measures (BIPM), pelayan dari sistem unit SI. Untuk menjawab pertanyaan Anda tentang pelebaran waktu, TAI didefinisikan sebagai waktu atom di permukaan laut (sebenarnya, di geoid, yang merupakan versi yang lebih bagus dari ide yang sama), dan setiap jam mengoreksi efek ketinggiannya sendiri.

  3. UTC (Waktu Universal Terkoordinasi). UTC ditetapkan sama dengan sepuluh detik di belakang TAI pada 1 Januari 1972, dan sejak tanggal itu ia mencentang ke depan pada tingkat yang persis sama dengan TAI, kecuali ketika lompatan kedua ditambahkan atau dikurangi. IERS membuat keputusan untuk mengumumkan lompatan kedua untuk menjaga perbedaan dalam 0,9 detik (dalam praktiknya, dalam waktu sekitar 0,6 detik; lompatan kedua yang ditambahkan menyebabkan perbedaannya berubah dari -0,6 ke +0,4). Secara teori, detik kabisat bisa positif dan negatif, tetapi karena rotasi bumi melambat dibandingkan dengan standar yang ditetapkan oleh SI dan TAI, detik kabisat negatif tidak pernah diperlukan dan mungkin tidak akan pernah.

  4. Waktu unix, yang melakukan yang terbaik untuk mewakili UTC sebagai angka tunggal. Setiap waktu Unix yang merupakan kelipatan dari 86.400 sesuai dengan tengah malam UTC. Karena tidak semua hari UTC panjangnya 86.400 detik, tetapi semua "Hari Unix" adalah, ada perbedaan yang tidak dapat didamaikan yang harus ditambal entah bagaimana. Tidak ada waktu Unix yang terkait dengan lompatan kedua yang ditambahkan. Dalam praktiknya, sistem akan bertindak seolah-olah detik sebelumnya terjadi dua kali (dengan cap waktu unix melompat mundur satu detik, kemudian melanjutkan ke depan lagi), atau menerapkan teknik seperti melompati lompatan yang melengkungkan waktu untuk jangka waktu yang lebih lama di kedua sisi lompatan kedua. Dalam kedua kasus ada beberapa ketidakakuratan, meskipun setidaknya yang kedua adalah monoton. Dalam kedua kasus tersebut,dan b tidak sama dengan ba; itu sama dengan ba ditambah jumlah detik kabisat intervensi .

Karena UT1, TAI, UTC, dan IERS semuanya adalah upaya multinasional di seluruh dunia, tidak ada satu pun "di mana", meskipun buletin IERS diterbitkan dari Observatorium Paris dan BIPM juga berbasis di Paris, itulah satu jawaban. Sebuah organisasi yang membutuhkan waktu yang tepat dan dapat dilacak dapat menyatakan basis waktu mereka sebagai sesuatu seperti "UTC (USNO)", yang berarti bahwa cap waktu mereka berada di UTC dan bahwa mereka berasal dari waktu di US Naval Observatory, tetapi mengingat masalah yang Saya sebutkan dengan waktu Unix, pada dasarnya tidak sesuai dengan tingkat ketepatan - siapa pun yang berurusan dengan waktu yang sangat tepat akan memiliki alternatif untuk waktu Unix.

hobbs
sumber
1
Anda telah mengabaikan keberadaan right/zona waktu dalam sistem Olson, dan bagaimana mereka memandangnya time_t.
JdeBP
1
@ JdeBP Saya sebenarnya belum pernah mendengar hal itu. Saya pikir itu agak meragukan untuk menyebut waktu Unix ketika itu jelas bertentangan dengan POSIX dan konvensi lama, tapi itu informasi yang berharga. Mungkin Anda bisa menambahkan jawaban tentang itu?
hobbs
1
Cara termudah untuk mendapatkan sumber waktu yang sangat akurat untuk orang awam adalah penerima GPS. Jam pada satelit disinkronkan ke TAI dan sinyalnya akurat sekitar 10⁻⁸ (tanpa koreksi; dengan koreksi dapat ditingkatkan menjadi 10⁻¹⁰).
Jan Hudec
1
@JanHudec Tidak seperti orang biasa yang bisa membedakan antara jam yang akurat hingga 10⁻² atau 10⁻¹⁰.
gerrit
1
Sekedar petunjuk mengapa UNIX tidak menyertakan dukungan leap second. Ini telah dibahas berkali-kali di teleconference Grup Austin dan hasilnya adalah menambahkan dukungan untuk detik kabisat akan menyebabkan lebih banyak masalah daripada menghilangkan dukungan akan menyebabkan.
schily
12

Penyesuaian jam dikoordinasikan oleh IERS. Mereka menjadwalkan penyisipan lompatan kedua ke dalam aliran waktu sesuai kebutuhan.

Dari The NTP Timescale dan Leap Seconds

The International Earth Rotation Jasa (IERS) di Paris Observatory menggunakan pengamatan astronomi yang disediakan oleh USNO dan observatorium lainnya untuk menentukan UT1 skala waktu (navigator) dikoreksi untuk variasi yang tidak teratur dalam rotasi Bumi.

Sepengetahuan saya 23:59:60 (Leap Second) dan 00:00:00 hari berikutnya dianggap sebagai detik yang sama di Unix Time.

BillThor
sumber
8

Waktu UNIX diukur pada komputer Anda, menjalankan UNIX.

Jawaban ini akan membuat Anda tahu apa itu Waktu Universal Terkoordinasi (UTC), Waktu Atom Internasional (TAI), dan SI kedua. Menjelaskan mereka jauh di luar lingkup Unix dan Linux Stack Exchange. Ini bukan Pertukaran Tumpukan Fisika atau Astronomi.

Perangkat keras

Komputer Anda berisi berbagai osilator yang mendorong jam dan timer. Persisnya apa yang berbeda dari komputer ke komputer tergantung pada arsitekturnya. Tetapi biasanya, dan secara umum:

  • Ada timer interval yang dapat diprogram (PIT) di suatu tempat, yang dapat diprogram untuk menghitung jumlah osilasi yang diberikan dan memicu interupsi ke unit pemrosesan pusat.
  • Ada penghitung siklus pada prosesor pusat yang hanya menghitung 1 untuk setiap siklus instruksi yang dieksekusi.

Teori operasi, dalam istilah yang sangat luas

Kernel sistem operasi menggunakan PIT untuk menghasilkan kutu . Ini mengatur PIT untuk menjalankan bebas, menghitung jumlah osilasi yang tepat untuk interval waktu, katakanlah, seperseratus detik, menghasilkan interupsi, dan kemudian secara otomatis mengatur ulang penghitungan untuk pergi lagi. Ada variasi dalam hal ini, tetapi pada dasarnya ini menyebabkan interupsi kutu dinaikkan dengan frekuensi tetap.

Dalam perangkat lunak, kernel menambahkan counter setiap centang. Ia mengetahui frekuensi centang, karena memprogram PIT sejak awal. Jadi ia tahu berapa banyak kutu yang membentuk sedetik. Ini dapat menggunakan ini untuk mengetahui kapan harus menambah penghitung yang menghitung detik. Yang terakhir ini adalah ide kernel dari "Waktu UNIX". Memang, memang, hanya menghitung ke atas pada tingkat satu per SI detik jika dibiarkan ke perangkat sendiri.

Empat hal menyulitkan ini, yang akan saya sampaikan secara umum.

Perangkat kerasnya tidak sempurna. Seorang PIT yang lembar datanya mengatakan bahwa ia memiliki frekuensi osilator N Hertz mungkin malah memiliki frekuensi (katakanlah) N .00002 Hertz, dengan konsekuensi yang jelas.

Skema ini interoperasinya sangat buruk dengan manajemen daya, karena CPU bangun ratusan kali per detik untuk melakukan sedikit lebih banyak daripada peningkatan angka dalam suatu variabel. Jadi beberapa sistem operasi memiliki apa yang dikenal sebagai desain "tickless". Alih-alih membuat PIT mengirim interupsi untuk setiap centang, kernel bekerja (dari penjadwal tingkat rendah) berapa banyak tick yang akan berlalu tanpa ada kuanta thread yang habis, dan memprogram PIT untuk menghitung berapa banyak tick ke dalam tick. masa depan sebelum mengeluarkan interupsi centang. Ia tahu bahwa itu kemudian harus merekam bagian dari kutu N pada interupsi kutu berikutnya, bukannya 1 kutu.

Perangkat lunak aplikasi memiliki kemampuan untuk mengubah waktu kernel saat ini. Itu bisa menginjak nilainya atau bisa membunuh nilainya. Slewing melibatkan menyesuaikan jumlah kutu yang harus naik untuk menambah penghitung detik. Jadi detik counter tidak selalu mengandalkan pada tingkat satu per SI detik pula , bahkan dengan asumsi osilator sempurna. Melangkah melibatkan hanya menulis nomor baru di penghitung detik, yang biasanya tidak akan terjadi sampai 1 SI detik sejak detik terakhir berlalu.

Kernel modern tidak hanya menghitung detik tetapi juga menghitung nanodetik. Tapi itu konyol dan sering tidak mungkin untuk memiliki interupsi centang sekali per nanodetik. Di sinilah hal-hal seperti penghitung siklus ikut berperan. Kernel mengingat nilai counter siklus pada setiap detik (atau pada setiap tick) dan dapat bekerja keluar, dari saat ini nilai counter ketika sesuatu ingin mengetahui waktu dalam nanodetik, berapa banyak nanodetik harus telah berlalu sejak detik terakhir (atau kutu). Namun, sekali lagi, manajemen daya dan termal memainkan malapetaka karena frekuensi siklus instruksi dapat berubah, sehingga kernel melakukan hal-hal seperti mengandalkan perangkat keras tambahan seperti (katakanlah) Pengatur Acara Presisi Tinggi (HPET).

Bahasa C dan POSIX

Standar perpustakaan bahasa C menggambarkan waktu dalam hal jenis buram, time_t, jenis struktur tmdengan berbagai bidang tertentu, dan berbagai perpustakaan fungsi seperti time(), mktime(), dan localtime().

Singkatnya: bahasa C sendiri hanya menjamin bahwa itu time_tadalah salah satu tipe data numerik yang tersedia dan bahwa satu-satunya cara yang dapat diandalkan untuk menghitung perbedaan waktu adalah difftime()fungsinya. Ini adalah standar POSIX yang memberikan jaminan lebih ketat yang time_tnotabene adalah salah satu dari tipe integer dan menghitung detik sejak Zaman . Ini juga merupakan standar POSIX yang menentukan timespectipe struktur.

The time()Fungsi kadang-kadang digambarkan sebagai panggilan sistem. Bahkan, ini belum menjadi panggilan sistem yang mendasarinya pada banyak sistem untuk waktu yang cukup lama, saat ini. Pada FreeBSD, misalnya, panggilan sistem yang mendasarinya adalah clock_gettime(), yang memiliki berbagai "jam" yang tersedia yang mengukur dalam detik atau detik + nanodetik dalam berbagai cara. Ini adalah panggilan sistem dimana perangkat lunak aplikasi membaca Waktu UNIX dari kernel. ( clock_settime()Panggilan sistem yang cocok memungkinkan mereka untuk melangkah dan adjtime()panggilan sistem memungkinkan mereka untuk mematikannya.)

Banyak orang melambaikan standar POSIX dengan klaim yang sangat pasti dan tepat tentang apa yang ditentukannya. Orang-orang seperti itu, lebih sering daripada tidak, tidak benar-benar membaca standar POSIX. Seperti dijelaskan alasannya, ide penghitungan "detik sejak Zaman", yang merupakan ungkapan yang digunakan standar, sengaja tidak menentukan bahwa POSIX detik sama panjangnya dengan SI detik, atau bahwa hasil dari gmtime()"tentu saja" UTC, terlepas dari penampilannya ". Standar POSIX sengajacukup longgar sehingga memungkinkan untuk (katakanlah) sistem UNIX di mana administrator pergi dan secara manual memperbaiki penyesuaian lompatan kedua dengan mengatur ulang jam seminggu setelah itu terjadi. Memang, alasan menunjukkan bahwa itu sengaja cukup longgar untuk mengakomodasi sistem di mana jam telah sengaja ditetapkan salah untuk beberapa waktu selain waktu UTC saat ini.

UTC dan TAI

Interpretasi Waktu UNIX yang diperoleh dari kernel adalah hingga rutinitas perpustakaan yang berjalan dalam aplikasi. POSIX menentukan identitas antara waktu kernel dan "waktu mogok" di a struct tm. Tetapi, seperti yang ditunjukkan oleh Daniel J. Bernstein, edisi standar tahun 1997 membuat identitas ini sangat salah, mengacaukan aturan tahun kabisat Kalender Gregorian (sesuatu yang dipelajari oleh anak sekolah) sehingga perhitungannya salah sejak tahun 2100 dan seterusnya. "Lebih terhormat dalam pelanggaran daripada ketaatan" adalah ungkapan yang mudah diingat.

Dan memang benar. Beberapa sistem saat ini mendasarkan interpretasi ini pada rutinitas perpustakaan yang ditulis oleh Arthur David Olson, yang merujuk pada "basis data zona waktu Olson" yang terkenal, biasanya dikodekan dalam file basis data di bawah /usr/share/zoneinfo/. Sistem Olson memiliki dua mode:

  • Kernel "detik sejak Zaman" dianggap menghitung detik UTC sejak 1970-01-01 00:00:00 UTC, kecuali untuk detik kabisat. Ini menggunakan posix/set file database zona waktu Olson. Semua hari memiliki 86400 detik kernel dan tidak pernah ada 61 detik dalam satu menit, tetapi mereka tidak selalu panjang SI detik dan jam kernel perlu slewing atau melangkah ketika lompatan detik terjadi.
  • Kernel "detik sejak Zaman" dianggap menghitung detik TAI sejak 1970-01-01 00:00:10 TAI. Ini menggunakan right/set file database zona waktu Olson. Kernel detik memiliki panjang 1 SI detik dan jam kernel tidak perlu slewing atau stepping untuk menyesuaikan detik kabisat, tetapi waktu yang rusak dapat memiliki nilai seperti 23:59:60 dan hari tidak selalu panjang 86400 kernel detik.

M. Bernstein menulis beberapa alat, termasuk daemontoolsalatnya, yang diperlukan right/karena mereka hanya menambahkan 10 time_tuntuk mendapatkan detik TAI sejak 1970-01-01 00:00:00 TAI. Dia mendokumentasikan ini di halaman manual.

Persyaratan ini (mungkin tanpa sadar) diwarisi oleh toolets seperti daemontools-encoredan runitdan oleh Felix von Leitner libowfat. Gunakan Bernsteinmultilog , Guentermultilog , atau Papesvlogd dengan posix/konfigurasi Olson , misalnya, dan semua cap waktu TAI64N akan (pada saat penulisan ini) 26 detik di belakang hitungan kedua TAI yang sebenarnya sejak 1970-01-01 00:00:10 TAI.

Laurent Bercot dan saya membahas ini dalam s6 dan nosh, meskipun kami mengambil pendekatan yang berbeda. M. Bercot tai_from_sysclock()bergantung pada bendera waktu kompilasi. alat nosh yang berurusan dengan TAI64N melihat variabel lingkungan TZdan TZDIRuntuk mendeteksi otomatis posix/dan right/jika mereka bisa.

Menariknya, dokumen time2posix()dan posix2time()fungsi FreeBSD yang memungkinkan setara dengan right/mode Olson dengan time_tsebagai TAI detik. Namun mereka tidak diaktifkan.

Sekali lagi…

Waktu UNIX diukur pada komputer Anda yang menjalankan UNIX, oleh osilator yang terdapat di perangkat keras komputer Anda. Itu tidak menggunakan SI detik; ini bukan UTC meskipun mungkin sangat mirip; dan itu dengan sengaja membuat jam Anda salah.

Bacaan lebih lanjut

JdeBP
sumber