UTC cambia dal 2027: perché il leap second era un problema per server e reti

Il tempo che governa il funzionamento della rete Internet sta per cambiare. Dal 20 maggio 2027, il Coordinated Universal Time (UTC), riferimento temporale utilizzato da sistemi operativi, server, reti di telecomunicazione e infrastrutture digitali, diventerà una scala temporale continua: una trasformazione destinata a eliminare la necessità di introdurre periodicamente i cosiddetti leap second, o secondi intercalari.

La decisione arriva dalla 28ª Conferenza generale dei pesi e delle misure (CGPM) che ha stabilito una data precisa per il superamento di un meccanismo utilizzato dal 1972 per mantenere sincronizzato il tempo atomico con la rotazione terrestre.

Non è un problema minore: un singolo secondo aggiunto o sottratto all’orologio mondiale può provocare anomalie nei sistemi informatici, alterare il comportamento dei software distribuiti e compromettere servizi che richiedono una sincronizzazione temporale rigorosa.

Perché gli orologi atomici e la Terra non vanno perfettamente d’accordo

Prima di proseguire, è bene distinguere due concetti che nella vita quotidiana tendiamo a considerare equivalenti: il tempo misurato dagli orologi atomici e quello ricavato dalla rotazione terrestre.

Il primo nasce da una definizione fisica estremamente precisa, legata al comportamento dell’atomo di cesio-133: non dipende dalla velocità con cui il nostro pianeta ruota.

Il secondo concetto riguarda invece UT1, una scala temporale associata all’angolo di rotazione della Terra rispetto a riferimenti astronomici. Poiché la rotazione terrestre non mantiene una velocità perfettamente costante, UT1 presenta piccole variazioni rispetto alle scale basate sugli orologi atomici.

A influenzare la rotazione intervengono diversi fenomeni: l’interazione gravitazionale con la Luna, i movimenti delle masse atmosferiche e oceaniche, i processi che interessano la conformazione interna del nostro pianeta e la redistribuzione delle masse.

Esiste poi il Tempo atomico internazionale (TAI), calcolato attraverso le misure fornite da laboratori metrologici distribuiti nel mondo: UTC procede alla stessa velocità del TAI, ma mantiene rispetto a quest’ultimo uno scarto espresso da un numero intero di secondi.

Che cos’è un leap second e perché può aggiungere un secondo alle 23:59:59

Il leap second, come abbiamo visto nel nostro articolo di approfondimento, è una correzione introdotta occasionalmente in UTC per compensare lo scostamento accumulato rispetto a UT1. Quando la differenza si avvicina alla soglia prevista, l’International Earth Rotation and Reference Systems Service (IERS) può annunciare l’inserimento di un secondo intercalare: così l’ultimo minuto di una giornata UTC può contenere eccezionalmente 61 secondi anziché 60. Il valore 23:59:60, per quanto insolito, rappresenta quindi un orario UTC valido durante l’inserimento di un secondo intercalare positivo.

L’ultimo intervento di questo tipo risale al 31 dicembre 2016. Da allora non sono stati introdotti altri secondi intercalari.

La procedura ha permesso per decenni di mantenere un collegamento stretto tra tempo civile e rotazione terrestre. Dal punto di vista informatico, però, introduce una complicazione: la durata di una giornata UTC non è sempre identica.

Molti programmi assumono implicitamente che un minuto contenga sempre 60 secondi e che ogni giornata duri esattamente 86.400 secondi. Tali ipotesi non sono universalmente valide quando entrano in gioco i leap second.

Anche la rappresentazione degli istanti richiede attenzione: i timestamp POSIX, comunemente utilizzati su Unix e Linux, adottano convenzioni che non rappresentano direttamente il secondo 23:59:60 come un istante distinto nella normale numerazione dei secondi.

Perché un secondo può mandare in crisi Linux, server e database

La difficoltà nasce dalla gestione delle discontinuità temporali nei sistemi software: un programma può utilizzare l’orologio di sistema per ordinare operazioni, calcolare timeout, registrare eventi o stabilire la durata di una transazione. Se quell’orologio ripete un valore, subisce una correzione improvvisa oppure si comporta diversamente da quanto previsto, alcuni algoritmi possono produrre risultati inattesi.

Durante l’introduzione del secondo intercalare del 30 giugno 2012, ad esempio, diversi servizi Internet subirono malfunzionamenti. Tra gli episodi più noti figurano problemi che coinvolsero sistemi Linux e piattaforme come Reddit e LinkedIn.

Il caso mostrò che un’aggiunta di appena un secondo poteva provocare effetti ben più rilevanti di uno scostamento temporale: alcuni sistemi registrarono consumi anomali di CPU e blocchi operativi.

Finora tutti i leap second effettivamente applicati sono stati positivi; tuttavia, la rotazione terrestre ha manifestato variazioni che rendono plausibile, in futuro, un intervento di segno opposto. Un secondo intercalare negativo comporterebbe l’eliminazione di un secondo dalla sequenza UTC: anziché passare normalmente da 23:59:58 a 23:59:59 e successivamente a 00:00:00, l’orologio dovrebbe saltare direttamente da 23:59:58 a 00:00:00.

Dal 20 maggio 2027 UTC diventerà continuo: che cosa cambia davvero

La risoluzione alla quale abbiamo fatto riferimento in apertura stabilisce due principi fondamentali:

• UTC diventerà una scala temporale continua a partire dal 20 maggio 2027;
• la differenza massima ammessa tra UT1 e UTC aumenterà fino a 3.600 secondi, equivalenti a un’ora.

Oggi il meccanismo dei leap second cerca di impedire che lo scostamento raggiunga un secondo; con la nuova impostazione, invece, il tempo atomico potrà allontanarsi gradualmente da quello associato alla rotazione terrestre senza richiedere continue correzioni.

La soglia di 3.600 secondi rappresenta il nuovo limite massimo consentito per la differenza tra due scale temporali, non certo una correzione da applicare immediatamente. Con il trascorrere dei decenni e dei secoli, UTC potrà accumulare uno scostamento sempre maggiore rispetto al tempo astronomico. CGPM considera il nuovo limite sufficiente a garantire la continuità di UTC per diversi secoli.

NTP e PTP: che cosa cambia per la sincronizzazione dei sistemi

La trasformazione coinvolge anche i protocolli utilizzati per sincronizzare gli orologi dei computer.

Il più conosciuto è Network Time Protocol (NTP), ampiamente utilizzato da server, workstation, apparati di rete e dispositivi collegati a Internet.

NTP consente di correggere l’orologio locale confrontandolo con riferimenti temporali esterni. Il protocollo dispone anche di informazioni dedicate alla segnalazione dei secondi intercalari, necessarie per preparare i sistemi agli eventuali aggiustamenti UTC. Il nuovo UTC continuo semplificherà il comportamento degli apparati sincronizzati.

Un discorso analogo riguarda Precision Time Protocol (PTP), definito dalla famiglia di standard IEEE 1588 e utilizzato negli ambienti che richiedono sincronizzazioni particolarmente precise.

PTP trova applicazione nelle reti industriali, nelle telecomunicazioni e nei sistemi che devono coordinare dispositivi con accuratezze molto elevate. Può distribuire riferimenti temporali associati a scale differenti e trasportare informazioni sugli scostamenti rispetto a UTC.

La decisione internazionale arriva comunque dopo molti anni durante i quali alcune grandi aziende tecnologiche hanno adottato soluzioni autonome per ridurre i rischi associati ai leap second. Una delle tecniche più conosciute prende il nome di leap smear: l’idea consiste nel non applicare improvvisamente un secondo aggiuntivo, ma nel distribuirne gradualmente l’effetto lungo un intervallo temporale sufficientemente ampio. Google, ad esempio, utilizza una soluzione che spalma la correzione su 24 ore.

GNSS, reti elettriche e telecomunicazioni: perché serve un tempo stabile

La sincronizzazione temporale non serve soltanto a visualizzare l’ora corretta. Nei sistemi di navigazione satellitare, ad esempio, la determinazione della posizione dipende dalla misurazione dei tempi di propagazione dei segnali radio. Piccolissimi errori temporali possono tradursi in errori significativi nella misura delle distanze.

I sistemi GNSS utilizzano scale temporali specifiche, con relazioni definite rispetto a UTC. Il GPS Time, per esempio, non introduce i secondi intercalari previsti da UTC; il suo scostamento rispetto al tempo civile deve quindi essere conosciuto e gestito.

Eliminare i leap second da UTC permetterà di rendere più stabile tale relazione, pur senza cancellare immediatamente gli scostamenti storici tra le diverse scale.

Anche le reti mobili utilizzano riferimenti temporali precisi per coordinare trasmissioni e apparati. Nelle reti energetiche, invece, una sincronizzazione accurata può risultare essenziale per confrontare misure effettuate in punti differenti, analizzare eventi e coordinare alcuni sistemi di protezione e controllo.

In tutti questi ambiti, il problema principale è l’evenienza in cui apparati diversi reagiscano in maniera incompatibile a una correzione improvvisa.