Guida alla sincronizzazione dell’ora del server

UTC, TAI, ora GPS e ora civile locale hanno scopi diversi. TAI (Tempo atomico internazionale) è una scala temporale atomica continua calcolata da BIPM dagli orologi che contribuiscono; non aggiunge secondi intercalari. UTC (Tempo Coordinato Universale) differisce dal TAI per un numero intero di secondi ed è il riferimento internazionale per i fusi orari civili. GPS Time era allineato con l’UTC all’inizio nel 1980 ma non aggiunge i secondi intercalari.

Secondo gli Stati Uniti Osservatorio navale, a partire da settembre 2026 il TAI è di 37 secondi e l’ora GPS è di 18 secondi avanti rispetto all’UTC. Questi offset possono cambiare in base alla futura politica dei secondi intercalari.

La definizione BIPM del secondo SI fissa la frequenza di transizione iperfine imperturbata dello stato fondamentale del cesio-133 a 9.192.631.770 Hz. Gli orologi al cesio utilizzano questa transizione atomica come riferimento di frequenza.

Gli standard primari e gli orologi ottici più recenti hanno incertezze di misura diverse; un singolo numero “un secondo in N anni” non può descrivere ogni dispositivo. Gli istituti nazionali di metrologia confrontano i loro standard e contribuiscono alle scale temporali internazionali. La distribuzione di tali standard tramite NTP è un processo separato dalla visualizzazione del browser di Clock-Tani, che non si collega direttamente a un orologio atomico.

Il Network Time Protocol (NTP) sincronizza gli orologi dei computer sulle reti. RFC 5905 (NTPv4) descrive una gerarchia di time server e un calcolo di offset utilizzando quattro timestamp: orari di invio e ricezione del client e orari di ricezione e trasmissione del server. Un client può utilizzare queste osservazioni per disciplinare il proprio orologio di sistema.

Le prestazioni dipendono dal riferimento del server, dall’orologio del dispositivo, dal ritardo della rete e dall’asimmetria. Gli esempi di reti locali veloci nella RFC non sono una promessa di precisione fissa per l’Internet pubblica o per ogni sistema operativo. Internet Time Service del NIST rileva che la precisione vista da un utente dipende in gran parte dalla stabilità e dalla reciprocità della rete.

Clock-Tani non esegue NTP nel browser né regola l’orologio del dispositivo. La sua pagina dell’ora del server stima una differenza rispetto alle risposte dell’API Web e ai tempi di andata e ritorno.

Gli orologi dei computer e dei telefoni dipendono dagli oscillatori hardware e dal cronometraggio del sistema operativo. La frequenza dell’oscillatore può variare in base alla temperatura, all’età e al design del dispositivo, ma non esiste una singola frequenza, un tasso di deriva giornaliero o un intervallo di sincronizzazione applicabile a ogni computer.

Molti sistemi operativi possono regolare periodicamente il proprio orologio utilizzando un servizio orario di rete quando abilitato e connesso. Il metodo e la pianificazione dipendono dalle impostazioni e dal dispositivo. Se un offset sembra inaspettato, controlla le impostazioni automatiche di ora e fuso orario; tratta il confronto del browser come una stima influenzata dalla rete. Domande frequenti sul cronometraggio del NIST illustra come gli errori dell’orologio al quarzo dipendano dall’oscillatore.

La pagina server-time predefinita effettua tre richieste all’API di Clock-Tani. Per ogni risposta aggiunge metà del tempo di andata e ritorno misurato dal browser al timestamp Date.now() dell’API, quindi seleziona il campione con la latenza media. Ciò riduce l’influenza di un valore anomalo lento; non si tratta di una sincronizzazione NTP o di una certificazione di precisione. Il ritorno alla pagina o la riconnessione alla rete possono attivare un’altra misurazione.

Per una vista specifica del sito, il server effettua una richiesta HEAD alla destinazione quando un risultato recente non è già memorizzato nella cache; un offset stimato valido può essere riutilizzato per un massimo di 60 secondi. Consulta l’intestazione della data HTTP della destinazione e il tempo di andata e ritorno, quindi misura separatamente l’hop API al browser. HTTP-date ha una risoluzione di un secondo. Intestazioni mancanti o inaffidabili possono portare a un’altra origine o ora del dispositivo, che l’interfaccia distingue. La correzione metà RTT presuppone ritardi simili in uscita e in ritorno e non può garantire una precisione fissa.

Secondo le attuali regole UTC, i secondi intercalari vengono utilizzati quando necessario per mantenere l’UTC vicino al tempo di rotazione terrestre (UT1). Il Bollettino IERS C annuncia se verrà introdotto un secondo intercalare. Un secondo intercalare positivo può inserire 23:59:60 dopo 23:59:59 in UTC, il che richiede che il software gestisca un minuto insolito.

Risoluzione CGPM 4 (2022) chiede di aumentare la differenza consentita UT1-UTC entro il 2035 o prima e di preparare un piano di implementazione per un UTC più continuo. Non specifica un metodo di aggiustamento già definitivo post-2035 né fa una promessa generale che tutta la gestione dei secondi intercalari termini in una data particolare.

I mercati finanziari, i sistemi di aviazione e navigazione, le reti di telecomunicazioni e le reti elettriche utilizzano tutti i tempi, ma la precisione e i metodi di convalida richiesti differiscono a seconda dell’applicazione. Ad esempio, il Regolamento delegato UE 2025/1155 sull’attività di negoziazione algoritmica ad alta frequenza specifica una divergenza UTC massima di 100 microsecondi per una particolare attività; questa non è una regola universale per tutti i settori o tutti i settori.

La navigazione satellitare, il coordinamento delle stazioni base e le misurazioni della rete hanno i propri requisiti temporali. Una visualizzazione del browser basata su risposte web, come Clock-Tani, non è un orologio convalidato per questi sistemi. Utilizzare la fonte temporale ufficiale e i record del sistema pertinente per decisioni consequenziali.

Apri la pagina dell’ora del server per confrontare l’orologio del tuo dispositivo con una stima Clock-Tani basata sulla risposta web. La visualizzazione predefinita accetta già tre campioni API e sceglie il risultato con latenza media; l’aggiornamento tre volte non trasforma tali offset in un errore del dispositivo "reale" certificato.

La pagina mostra un offset stimato in millisecondi, non un valore di ritardo di andata e ritorno misurato o una diagnosi dello stato NTP del sistema operativo. Utilizza "Sincronizza di nuovo" dopo una modifica della connessione se desideri un altro preventivo. Se una differenza persistente sembra inaspettata, controlla le impostazioni automatiche dell’ora e del fuso orario del tuo dispositivo. Non esiste una soglia universale di normalità/attenzione/serietà per questa misurazione del browser e il riavvio non è un prerequisito generale prima di un evento urgente.

La pagina dell’ora del server di Clock-Tani visualizza un riferimento basato sulla risposta Web accanto all’ora del dispositivo e ne stima la differenza. La fonte predefinita è il timestamp API di Clock-Tani; una vista specifica del sito può utilizzare l’intestazione HTTP Date del target o un fallback chiaramente indicato.

Questo confronto non può stabilire se il servizio NTP del tuo computer funziona, certificare un errore assoluto o verificare l’orario di apertura interno del venditore di biglietti. Il ritardo della rete e l’errore dell’orologio del server possono influenzarlo. Per vendite, esami e altre scadenze consequenziali, fare affidamento sugli annunci ufficiali dell’organizzatore e sui registri di presentazione. Lo strumento può aiutarti a osservare e ricontrollare un riferimento e può contare alla rovescia fino al tempo impostato.