Disclaimerish cosa:

Ho appena esaminato l'elenco dei siti StackExchange per circa 20 minuti cercando di capire dove pubblicare questo. Se conosci qualche sito più adatto, ti preghiamo di spostare questa domanda lì. Sto pubblicando questo qui perché il tempo unix mi ha fatto pensare.

Quindi, come tutti sappiamo, c'è unix time e c'è UTC. Il tempo di Unix continua a scorrere, contando i secondi - un secondo al secondo -, mentre UTC cerca di mantenere il tempo nei formati leggibili dall'uomo che usiamo in linea con la fase terrestre nella sua rotazione. Per fare ciò, UTC inserisce di volta in volta secondi saltati.

Poiché il tempo è relativo alla forza gravitazionale a cui è esposto l'oggetto che sperimenta il tempo, altri tipi di accelerazione e velocità relativa, ciò porta a 2 domande. Superiamo prima quello semplice: dove viene misurato il tempo unix? Se Alice e Bob iniziano a concordare che l'ora corrente è 1467932496.42732894722748 quando si trovano nello stesso posto (un secondo corso viene definito come 9'192'631'770 cicli di radiazione corrispondenti alla transizione tra due livelli di energia del cesio-133 atomo a riposo e a 0 K), sperimenta un paradosso gemello dovuto ad Alice che vive sul livello del mare e Bob che vive in alto nelle montagne o Alice che vive al polo nord e Bob che vive all'equatore, non saranno più d'accordo. Quindi, come viene definito precisamente il tempo unix?

All'inizio potresti non vedere il problema con UTC perché sicuramente tutti possono essere d'accordo sul fatto che la Terra abbia completato un'orbita (questo ovviamente ignora il movimento della piastra continentale ma penso che lo capiamo abbastanza bene perché con il GPS è possibile misurare il loro movimento molto precisamente e possiamo supporre che si trovino in una posizione prestabilita nel nostro modello e non si muovano mentre si spostano le placche continentali), non importa se si trovano su una montagna, sul livello del mare, sull'equatore o sul polo nord. Potrebbero esserci delle differenze di tempo ma non si accumulano.

Ma un secondo è definito come 9'192'631'770 cicli di radiazione corrispondenti alla transizione tra due livelli di energia dell'atomo di cesio 133 a riposo e a 0 K e l'atomo di cesio 133 non si preoccupa dell'orbita terrestre. Quindi UTC decide dove inserire un secondo di salto, ma deve esserci uno spostamento misurato o previsto tra la fase dell'orbita terrestre e il tempo misurato da qualche parte da un orologio atomico. Dov'è questo da qualche parte?

La tua domanda principale non ha una vera risposta; Il tempo di Unix non è un vero calendario e non è "misurato" da nessuna parte. È una rappresentazione di UTC, anche se povera perché ci sono momenti in UTC che non può rappresentare. Il tempo Unix insiste sul fatto che ogni giorno ci sono 86.400 secondi, ma UTC si discosta da quello a causa dei secondi saltati.

Per quanto riguarda la tua domanda più ampia, ci sono quattro importanti tempistiche di interesse:

1. UT1 (Universal Time), che viene calcolato dagli osservatori di tutto il mondo che misurano la rotazione della Terra rispetto alle stelle fisse. Con queste osservazioni e un po 'di matematica, otteniamo una versione più moderna del vecchio Greenwich Mean Time, che si basava sul momento del mezzogiorno solare al Royal Observatory di Greenwich. Il tempo universale è calcolato da un'organizzazione denominata IERS (International Earth Rotation and Reference Systems Service, precedentemente International Earth Rotation Service).

2. TAI (International Atomic Time), che è tenuto da centinaia di orologi atomici in tutto il mondo, gestito da organismi di standard nazionali e simili. I custodi degli orologi che contribuiscono al TAI utilizzano tecniche di trasferimento del tempo per orientare gli orologi l'uno verso l'altro, annullando eventuali piccoli errori dei singoli orologi e creando un tempo di insieme; quell'insieme è TAI, pubblicato dall'International Bureau of Weights and Measures (BIPM), gli amministratori del sistema di unità SI. Per rispondere alla tua domanda sulla dilatazione del tempo, il TAI è definito come tempo atomico a livello del mare (in realtà, al geoide, che è una versione più elaborata della stessa idea), e ogni orologio corregge gli effetti della propria altitudine.

3. UTC (Coordinated Universal Time). Il 1 ° gennaio 1972 l'UTC era pari a dieci secondi indietro rispetto al TAI e da quella data scorre in avanti esattamente allo stesso ritmo del TAI, tranne quando viene aggiunto o sottratto un secondo di salto. Lo IERS decide di annunciare un secondo di salto per mantenere la differenza entro 0,9 secondi (in pratica, entro circa 0,6 secondi; un secondo di salto aggiuntivo fa sì che la differenza passi da -0,6 a +0,4). In teoria, i secondi di salto possono essere sia positivi che negativi, ma poiché la rotazione della terra sta rallentando rispetto allo standard stabilito da SI e TAI, un secondo di salto negativo non è mai stato necessario e probabilmente non lo sarà mai.

4. Tempo Unix, che fa del suo meglio per rappresentare UTC come un singolo numero. Ogni ora Unix che è un multiplo di 86.400 corrisponde alla mezzanotte UTC. Dal momento che non tutti i giorni UTC sono lunghi 86.400 secondi, ma tutti i "giorni Unix" lo sono, c'è una differenza inconciliabile che deve essere patchata in qualche modo. Non c'è tempo Unix corrispondente ad un secondo salto in più. In pratica, i sistemi agiranno come se il secondo precedente si fosse verificato due volte (con il timestamp unix che salta indietro di un secondo, quindi procedendo di nuovo in avanti), oppure applicheranno una tecnica come lo sbalzo del salto che deforma il tempo per un periodo di tempo più lungo su entrambi i lati del un secondo bisestile. In entrambi i casi c'è una certa imprecisione, sebbene almeno il secondo sia monotonico. In entrambi i casi,e b non è uguale a ba; è uguale a ba più il numero di secondi intercalari intercorrenti .

Poiché UT1, TAI, UTC e IERS sono tutti sforzi multinazionali in tutto il mondo, non esiste un unico "dove", sebbene i bollettini IERS siano pubblicati dall'Osservatorio di Parigi e anche il BIPM abbia sede a Parigi, questa è una risposta. Un'organizzazione che richiede tempo preciso e tracciabile potrebbe indicare la propria base temporale come qualcosa di simile a "UTC (USNO)", il che significa che i loro timestamp sono in UTC e che sono derivati ​​dal tempo all'Osservatorio navale degli Stati Uniti, ma dati i problemi che Ho accennato al tempo di Unix, è sostanzialmente incompatibile con quel livello di precisione: chiunque abbia a che fare con un tempo veramente preciso avrà un'alternativa al tempo di Unix.

Le regolazioni dell'orologio sono coordinate da IERS. Pianificano l'inserimento di un secondo di salto nel flusso temporale come richiesto.

Da The NTP Timescale e Leap Seconds

L' International Earth Rotation Service (IERS) presso l'Osservatorio di Parigi utilizza le osservazioni astronomiche fornite dall'USNO e da altri osservatori per determinare la scala temporale UT1 (navigatore) corretta per variazioni irregolari nella rotazione terrestre.

Per quanto ne so, 23:59:60 (secondo bisestile) e 00:00:00 del giorno successivo sono considerati lo stesso secondo in Unix Time.

Il tempo UNIX viene misurato sul tuo computer, con UNIX.

Questa risposta si aspetta che tu sappia che cosa sono il Tempo universale (UTC), il Tempo atomico internazionale (TAI) e il secondo SI. Spiegarli è ben oltre lo scopo di Unix e Linux Stack Exchange. Non si tratta degli scambi di stack di fisica o astronomia.

L'hardware

Il computer contiene vari oscillatori che guidano orologi e timer. Esattamente quello che ha varia da computer a computer a seconda della sua architettura. Ma di solito, e in termini molto generali:

• C'è un timer di intervallo programmabile (PIT) da qualche parte, che può essere programmato per contare un determinato numero di oscillazioni e innescare un interruzione all'unità centrale di elaborazione.
• C'è un contatore di cicli sul processore centrale che conta semplicemente 1 per ogni ciclo di istruzioni che viene eseguito.

La teoria del funzionamento, in termini molto ampi

Il kernel del sistema operativo utilizza PIT per generare tick . Imposta il PIT in modalità di esecuzione libera, contando il giusto numero di oscillazioni per un intervallo di tempo, diciamo, un centesimo di secondo, generando un interrupt e quindi ripristinando automaticamente il conteggio per procedere nuovamente. Vi sono variazioni al riguardo, ma in sostanza ciò provoca un aumento dell'intervallo di tick con una frequenza fissa.

Nel software, il kernel incrementa un contatore ogni tick. Conosce la frequenza di tick, perché ha programmato il PIT in primo luogo. Quindi sa quante zecche compongono un secondo. Può usarlo per sapere quando incrementare un contatore che conta i secondi. Quest'ultima è l'idea del kernel di "UNIX Time". In effetti, conta semplicemente verso l'alto al ritmo di uno al secondo SI se lasciato ai propri dispositivi.

Quattro cose complicano ciò, che presenterò in termini molto generali.

L'hardware non è perfetto. Un PIT la cui scheda tecnica dice che ha una frequenza dell'oscillatore di N Hertz potrebbe invece avere una frequenza (diciamo) di N .00002 Hertz, con ovvie conseguenze.

Questo schema interagisce molto male con la gestione dell'alimentazione, perché la CPU si sta svegliando centinaia di volte al secondo per fare poco più che incrementare un numero in una variabile. Quindi alcuni sistemi operativi hanno quelli che sono noti come design "tickless". Invece di fare in modo che il PIT invii un interrupt per ogni tick, il kernel risolve (dallo scheduler di basso livello) quante tick passeranno senza quanti thread si esauriranno e programma il PIT per contare quel numero di tick nel futuro prima di emettere un interruzione tick. Sa che deve quindi registrare il passaggio di N tick alla successiva interruzione tick, anziché 1 tick.

Il software applicativo ha la capacità di cambiare l'ora corrente del kernel. Può passo il valore o può uccise il valore. La rotazione comporta la regolazione del numero di tick che devono passare per aumentare il contatore dei secondi. Così i secondi contatore non necessariamente contare al ritmo di una al secondo SI comunque , anche ammettendo oscillatori perfette. Lo stepping implica semplicemente la scrittura di un nuovo numero nel contatore dei secondi, che di solito non avverrà fino a 1 secondo SI dall'ultimo secondo spuntato.

I kernel moderni non solo contano i secondi, ma contano anche i nanosecondi. Ma è ridicolo e spesso assolutamente impossibile avere un interruzione tick una volta per nanosecondo. Qui entrano in gioco cose come il contatore del ciclo . Il kernel ricorda il valore del contatore del ciclo ad ogni secondo (o ad ogni tick) e può calcolare, dal valore corrente del contatore quando qualcosa vuole sapere il tempo in nanosecondi, quanti nanosecondi devono essere trascorsi dall'ultimo secondo (o tick). Anche in questo caso, tuttavia, la gestione dell'alimentazione e del calore causa un disastro poiché la frequenza del ciclo di istruzione può cambiare, quindi i kernel fanno cose come fare affidamento su hardware aggiuntivo come (diciamo) un Timer di eventi ad alta precisione (HPET).

Il linguaggio C e POSIX

La libreria standard del linguaggio C descrive tempo in termini di un tipo, opaco time_t, un tipo di struttura tmcon vari campi specifici, e varie funzioni di libreria come time(), mktime()e localtime().

In breve: il linguaggio C stesso garantisce semplicemente che time_tè uno dei tipi di dati numerici disponibili e che l'unico modo affidabile per calcolare le differenze temporali è la difftime()funzione. È lo standard POSIX che fornisce le garanzie più rigorose che time_tè in realtà uno dei tipi interi e che conta secondi dall'epoca . È anche lo standard POSIX che specifica il timespectipo di struttura.

La time()funzione è talvolta descritta come una chiamata di sistema. In effetti, al giorno d'oggi non è stata la chiamata di sistema sottostante su molti sistemi per molto tempo. Su FreeBSD, ad esempio, è la chiamata di sistema sottostante clock_gettime(), che ha vari "clock" disponibili che misurano in secondi o secondi + nanosecondi in vari modi. È questa chiamata di sistema mediante la quale il software applicativo legge UNIX Time dal kernel. (Una clock_settime()chiamata di sistema corrispondente consente loro di eseguirla e una adjtime()chiamata di sistema consente loro di spostarla.)

Molte persone agitano lo standard POSIX con affermazioni molto precise ed esatte su ciò che prescrive. Queste persone, il più delle volte, non hanno letto lo standard POSIX. Come enunciato nella sua logica, l'idea di contare "secondi dall'epoca", che è la frase usata dallo standard, non specifica intenzionalmente che i secondi POSIX hanno la stessa lunghezza dei secondi SI, né che il risultato di gmtime()è "necessariamente UTC, nonostante il suo aspetto ". Lo standard POSIX è intenzionalmenteabbastanza libero da consentire (diciamo) un sistema UNIX in cui l'amministratore va e corregge manualmente le regolazioni del secondo intercalare reimpostando l'orologio la settimana dopo che si verificano. In effetti, la logica sottolinea che è intenzionalmente abbastanza lento da contenere sistemi in cui l'orologio è stato deliberatamente impostato in modo errato su un orario diverso dall'ora UTC corrente.

UTC e TAI

L'interpretazione di UNIX Time ottenuta dal kernel dipende dalle routine di libreria in esecuzione nelle applicazioni. POSIX specifica un'identità tra il tempo del kernel e un "tempo scaduto" in a struct tm. Ma, come ha sottolineato una volta Daniel J. Bernstein, l'edizione del 1997 dello standard ha ottenuto questa identità imbarazzantemente sbagliata, confondendo la regola dell'anno bisestile del Calendario Gregoriano (qualcosa che gli scolari imparano) in modo che il calcolo fosse errato dal 2100 in poi. "Più onorato nella violazione che nell'osservanza" è una frase che mi viene subito in mente.

E infatti lo è. Diversi sistemi oggi basano questa interpretazione sulle routine di libreria scritte da Arthur David Olson, che consultano il famigerato "database del fuso orario Olson", solitamente codificato in file di database /usr/share/zoneinfo/. Il sistema Olson aveva due modalità:

• I "secondi dall'epoca" del kernel sono considerati conteggi dei secondi UTC dal 1970-01-01 00:00:00 UTC, fatta eccezione per i secondi bisestili. Questo utilizza il posix/set di file di database del fuso orario di Olson. Tutti i giorni hanno 86400 secondi del kernel e non ci sono mai 61 secondi in un minuto, ma non sono sempre la lunghezza di un secondo SI e l'orologio del kernel deve essere ruotato o fatto avanzare quando si verificano i secondi bisestili.
• I "secondi dall'epoca" del kernel sono considerati TAI secondi dal 1970-01-01 00:00:10 TAI. Questo utilizza il right/set di file di database del fuso orario di Olson. I secondi del kernel sono lunghi 1 SI secondo e l'orologio del kernel non ha mai bisogno di rotazione o stepping per regolare i secondi bisestili, ma i tempi di rottura possono avere valori come 23:59:60 e i giorni non sono sempre lunghi 86400 secondi del kernel.

M. Bernstein scrisse diversi strumenti, incluso il suo daemontoolsset di strumenti, che richiedevano right/perché semplicemente aggiungevano 10 time_tper ottenere secondi TAI dal 1970-01-01 00:00:00 TAI. Lo ha documentato nella pagina del manuale.

Questo requisito è stato (forse inconsapevolmente) ereditata dal set di strumenti, come daemontools-encoree runite di Felix von Leitner di libowfat. Usa Bernsteinmultilog , Guentermultilog o Papesvlogd con una posix/configurazione Olson , per esempio, e tutti i timestamp TAI64N saranno (al momento della stesura di questo) 26 secondi indietro rispetto al secondo conteggio TAI effettivo dal 1970-01-01 00:00:10 TAI.

Laurent Bercot e io abbiamo affrontato questo problema in s6 e nosh, anche se abbiamo adottato approcci diversi. M. Bercot si tai_from_sysclock()affida a una bandiera di compilazione. Gli strumenti nosh che si occupano di TAI64N esaminano le variabili di ambiente TZe TZDIRper rilevare automaticamente posix/e right/se possono.

È interessante notare che i documenti time2posix()e le posix2time()funzioni di FreeBSD che consentono l'equivalente della right/modalità Olson con time_tsecondi TAI. Apparentemente non sono abilitati, tuttavia.

Di nuovo…

Il tempo UNIX viene misurato sul computer su cui è in esecuzione UNIX, tramite oscillatori contenuti nell'hardware del computer. Non usa secondi SI; non è UTC anche se può assomigliarlo superficialmente; e consente intenzionalmente al tuo orologio di essere sbagliato.

Ulteriori letture

• Daniel J. Bernstein. Ora UTC, TAI e UNIX . cr.yp.to.
• Daniel J. Bernstein. tai64nlocal. strumenti del demonio. cr.yp.to.
• " secondi dall'epoca ". Specifica singola UNIX versione 2 . 1997. The Open Group.
• " Seconds Since the Epoch (Rationale) ". Specifiche di base Numero 6 . 2004. IEEE 1003.1. The Open Group.
• David Madore (17-12-2010). Il secondo disastro di Unix .
• time2posix. Manuale di FreeBSD 10.3. § 3.
• /physics/45739/
• /astronomy/11840/