Cos'è il database dei fusi orari IANA (e perché è importante)

Quando il tuo portatile arretra silenziosamente di un'ora una domenica mattina, oppure quando un invito al calendario da parte di un collega di São Paulo arriva esattamente nel momento che ti aspettavi, è la stessa cosa invisibile ad aver fatto il lavoro: un insieme di dati mantenuto liberamente che quasi ogni sistema operativo, linguaggio di programmazione e servizio web tratta come l'autorità sull'ora civile. È il database dei fusi orari IANA — chiamato anche database tz, tzdata o, storicamente, database Olson, dal nome di Arthur David Olson, che cominciò a mantenerlo negli anni Ottanta.

I fusi orari sembrano geografia, ma sono politica. Un governo può decidere di terminare in anticipo l'ora legale, modificare il proprio offset standard o saltare un giorno intero — talvolta con un preavviso di poche settimane. Il database tz è il regolamento condiviso che assorbe questi cambiamenti, così che alla domanda "che ora sono le 15:00 di New York a Londra?" corrisponda una sola risposta coerente ovunque. Questo articolo spiega cosa contiene realmente il database, come un aggiornamento viaggia da un decreto governativo fino al tuo telefono e perché la scorciatoia allettante di memorizzare un offset fisso come "UTC+1" è un bug in attesa di manifestarsi.

Che cos'è realmente il database

Il database tz è un insieme di file di testo semplice che descrivono le regole dell'ora locale degli orologi in tutto il mondo — sia oggi sia quanto indietro lo consentano ragionevolmente i registri. Non lo si esegue; sono i software a leggerlo. Chiunque può scaricarlo, e i dati non comportano restrizioni di licenza, il che è parte del motivo per cui è finito ovunque.

Ogni regione è identificata da un nome di zona nella forma `Area/Località`: `America/New_York`, `Europe/London`, `Asia/Kolkata`, `Australia/Lord_Howe`. La località è solitamente una città rappresentativa, non un paese, e questo è voluto. Un singolo paese può coprire diversi insiemi di regole, e i nomi delle città sono molto più stabili nel corso dei decenni rispetto ai confini o ai nomi dei paesi. Il database definisce alcune centinaia di queste zone.

Per ciascuna zona, i dati registrano:

• L'offset di base rispetto a UTC — per esempio, `America/New_York` è UTC−5 in inverno (EST).
• Le regole dell'ora legale in vigore, incluso esattamente quando iniziano e finiscono ogni anno.
• Le transizioni storiche — ogni cambiamento passato dell'offset o della regola DST di quella zona.
• Le abbreviazioni applicate in ciascun periodo, come EST, EDT, CET o IST.

È questa dimensione storica a distinguere tzdata da una semplice tabella di offset. Non sa soltanto che oggi New York è UTC−5. Sa che gli Stati Uniti hanno anticipato la data di inizio dell'ora legale a partire dal 2007, e applica la regola corretta per qualunque data tu chieda. È per questo che un convertitore ben costruito può indicarti l'offset per una data del 1995 con la stessa sicurezza con cui lo fa per martedì prossimo.

Zone, link e le confuse voci "Etc"

Il database definisce anche i link — alias che puntano un nome a un altro, così che le ridenominazioni non rompano i sistemi esistenti. Quando la zona dell'India si è assestata su `Asia/Kolkata`, il più vecchio `Asia/Calcutta` è stato mantenuto come link a essa. Entrambi continuano a risolversi in UTC+5:30.

Esistono anche le zone `Etc/` per gli offset fissi, tra cui `Etc/UTC` e la famigerata e controintuitiva `Etc/GMT+5`. Quest'ultima è UTC−5, non UTC+5: i nomi `Etc/GMT±` invertono il segno secondo una vecchia convenzione POSIX. Queste zone a offset fisso esistono per esigenze tecniche di nicchia. Per qualsiasi luogo in cui vivono persone reali, conviene una zona geografica — perché solo una zona geografica conosce l'ora legale e i futuri cambiamenti di regole. La prossima sezione spiega perché ciò conta.

Perché le regole dei fusi orari cambiano così spesso

Si dà per scontato che i fusi orari siano stabiliti. Non lo sono. Il database tz viene aggiornato diverse volte in un anno tipico, a volte di più. Le release sono versionate con l'anno e una lettera — `2023a`, `2023b`, `2024a` — e ciascuna raccoglie tutti i cambiamenti di regole e le correzioni accumulatisi dall'ultima.

I cambiamenti provengono da una manciata di fonti ricorrenti:

• Governi che modificano la politica sull'ora legale. Un paese comincia a osservare l'ora legale, smette, o sposta le date di transizione. L'Unione Europea discute da anni dell'abolizione del cambio stagionale dell'ora, e diversi stati americani hanno approvato leggi che chiedono l'ora legale permanente, in attesa dell'approvazione federale.
• Cambiamenti totali di offset. Occasionalmente un territorio adotta un'ora standard del tutto diversa. Il caso classico: alla fine del 2011, le Samoa hanno saltato del tutto il 30 dicembre, passando dall'altra parte della linea internazionale del cambio di data per allineare la propria settimana lavorativa con l'Australia e la Nuova Zelanda anziché con la costa occidentale degli Stati Uniti.
• Annunci con breve preavviso. Questa è la parte difficile. Un governo a volte annuncia un cambiamento settimane — o giorni — prima che entri in vigore. I manutentori e i fornitori a valle si affrettano allora a rilasciare e distribuire un aggiornamento prima che arrivi la data.
• Correzioni storiche. I ricercatori scovano vecchie norme, archivi di giornali o orari ferroviari che precisano quale *fosse* l'offset di una zona decenni fa, e anche queste correzioni vengono integrate.

La conclusione netta: la regola di un luogo è nota solo fino alla prossima decisione governativa. Qualsiasi sistema che presuma che le regole odierne siano permanenti prima o poi sbaglierà.

Come un aggiornamento raggiunge il tuo telefono

Il database è mantenuto da una comunità di volontari che si coordinano su una mailing list pubblica, con IANA (l'Internet Assigned Numbers Authority) che funge da sede ufficiale e punto di distribuzione. Un cambiamento viaggia tipicamente così:

1. Qualcuno lo segnala sulla mailing list tz, citando di solito una gazzetta ufficiale governativa, un annuncio ufficiale o una ricerca da fonti primarie. 2. I manutentori lo verificano e lo discutono, poi inviano la modifica al file di dati pertinente. 3. IANA pubblica una nuova release con un tag di versione come `2024a`. 4. I consumatori a valle la integrano — distribuzioni Linux, macOS, runtime dei linguaggi e le principali piattaforme. (Windows mantiene il proprio formato dei fusi orari e lo mappa sui nomi IANA.) 5. Il tuo dispositivo la recepisce tramite un aggiornamento del sistema operativo, un aggiornamento di un'app o, sui server, un pacchetto come `tzdata`.

Questa pipeline è anche il punto in cui nascono i bug del mondo reale. Il database può essere perfettamente aggiornato mentre un dispositivo specifico non lo è. Un portatile che ha mancato l'aggiornamento continua ad applicare la vecchia regola, e l'orologio è sbagliato nel giorno della transizione. Il divario tra "la regola è cambiata" e "ogni dispositivo lo sa" è la singola maggiore fonte di bug sui fusi orari che incontrerai davvero.

Perché gli offset codificati a mano diventano obsoleti

Ecco l'errore che l'intero sistema esiste per prevenire. Uno sviluppatore decide di memorizzare il fuso orario di un utente come semplice numero — `+1` — perché sembra efficiente. È sbagliato in tre modi contemporaneamente.

• Ignora l'ora legale. `Europe/Paris` è UTC+1 in inverno e UTC+2 in estate. Un `+1` memorizzato è corretto solo per una parte dell'anno, e ogni primavera e autunno il calcolo si discosta di un'ora.
• Non può rappresentare la transizione stessa. La mattina in cui l'orologio va avanti, un'ora locale non esiste; la mattina in cui torna indietro, un'ora locale accade due volte. Un semplice offset non ha modo di dire "le 02:30 sono accadute due volte". Una zona con nome, applicata tramite una corretta logica delle date, sì.
• Congela una regola che cambierà. Se una regione abolisce l'ora legale l'anno prossimo, il database tz rilascia un aggiornamento e ogni sistema conforme si adatta automaticamente. Un `+1` codificato a mano continua ad applicare per sempre la politica dell'anno scorso, producendo silenziosamente orari sbagliati.

Un esempio svolto, con offset verificati

Pianifica una chiamata ricorrente per ogni lunedì alle 09:00 a Berlino, a cui partecipa qualcuno a Chicago. Osserva come il divario si sposta nel corso dell'anno:

• Metà gennaio: Berlino è su CET (UTC+1), Chicago è su CST (UTC−6). Il divario è di 7 ore, quindi la chiamata è alle 02:00 a Chicago.
• Metà luglio: entrambe sono passate all'ora estiva — Berlino CEST (UTC+2), Chicago CDT (UTC−5). Sempre 7 ore, quindi ancora le 02:00 a Chicago.
• Metà marzo: i due paesi *non* cambiano lo stesso giorno. Nel 2025 gli Stati Uniti sono andati avanti il 9 marzo, ma l'UE solo il 30 marzo. Per quelle tre settimane Chicago era già su CDT (UTC−5) mentre Berlino era ancora su CET (UTC+1) — un divario di sole 6 ore, che rende la chiamata alle 03:00 a Chicago.

Uno strumento che memorizzasse "Berlino = +1, Chicago = −6" sbaglierebbe di un'ora a luglio *e* durante le settimane di sovrapposizione di marzo. Solo un sistema che risolve le zone con nome rispetto alla *data specifica* azzecca ogni settimana. È esattamente così che funzionano il pianificatore di riunioni e il convertitore di Timezio: chiedono quale luogo intendi, poi applicano le regole in vigore per la data in questione anziché un numero congelato.

Una checklist pratica

Non hai mai bisogno di aprire un file tzdata per beneficiare del suo funzionamento. Cinque abitudini portano questo valore nell'uso quotidiano:

• Memorizza e condividi luoghi, non offset. "Sono in `America/Los_Angeles`" sopravvive all'ora legale e ai cambiamenti di politica. "Sono a UTC−8" no.
• Tieni aggiornati i tuoi sistemi. Il motivo più comune per cui un orologio è sbagliato in un fine settimana di transizione è un dispositivo che ha mancato l'ultima release di `tzdata`. Gli aggiornamenti del sistema operativo e delle app sono il modo in cui la correzione ti raggiunge.
• Diffida di qualsiasi strumento che mostri un singolo offset fisso per una città. Se non sa tenere conto della data, non sa tenere conto dell'ora legale.
• Ricontrolla gli eventi transfrontalieri attorno ai fine settimana di cambio dell'ora e dopo qualsiasi annuncio governativo. È esattamente quando il divario regola-contro-aggiornamento morde più forte.
• Tratta ogni risposta come provvisoria. La conversione corretta di oggi è corretta solo fino al prossimo decreto.

Il database dei fusi orari IANA è uno dei pezzi più silenziosi di infrastruttura condivisa online — un insieme di file di testo mantenuto da volontari su cui il mondo digitale si appoggia per l'ora civile. Funziona perché tratta i fusi orari per quello che realmente sono: un bersaglio mobile plasmato dalla politica, non una griglia fissa disegnata su una mappa. Ogni conversione accurata su cui fai affidamento, compresa quella di Timezio, dipende dal fatto che qualcuno, da qualche parte, abbia annotato l'ultima regola e l'abbia distribuita prima che gli orologi cambiassero.