IANA timezone

Un IANA timezone è un identificatore canonico come Europe/London, America/New_York, o Asia/Tokyodal database IANA Time Zone (chiamato anche “tzdata” o “database Olson” dal nome del suo ideatore originale, Arthur David Olson).

Ogni voce cattura tutte le regole storiche e attuali relative all’offset UTC e al comportamento dell’ora legale per una regione. “Europe/London” codifica: GMT (UTC+0) in inverno, BST (UTC+1) in estate, le date precise di transizione dell’ora legale, e le particolarità storiche precedenti al 1971. Inserendo una data e un fuso in qualsiasi linguaggio di programmazione moderno si ottiene l’offset corretto perché tzdata è integrato nel sistema operativo.

La convenzione di denominazione è Regione/Città, dove Regione è una tra Africa, America, Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacific, più i valori speciali UTC, Etc/GMT, ecc. Città è una città canonica all’interno del fuso — Istanbul rappresenta tutta la Turchia, New_York rappresenta il fuso orario Eastern degli Stati Uniti, e così via.

Il convertitore di fusi orari di Convertitive si basa sul tzdata a livello di sistema operativo del browser tramite Intl.DateTimeFormat, così le transizioni dell’ora legale e le variazioni di offset sono sempre aggiornate senza che Convertitive debba rilasciare aggiornamenti.

Esempio pratico

Stai pianificando una riunione settimanale ricorrente alle “09:00 di martedì ora di New York” per partecipanti a NYC, Londra e Tokyo. Memorizza la riunione come { rrule: "FREQ=WEEKLY;BYDAY=TU", time: "09:00", tz: "America/New_York" }. Il calendario del partecipante londinese risolve ogni occorrenza: a gennaio, NY è su EST (UTC−5) e Londra su GMT (UTC+0), quindi la riunione è alle 14:00 a Londra. A marzo (dopo l’inizio dell’ora legale USA ma prima di quella europea), NY è su EDT (UTC−4) e Londra su GMT, quindi la riunione è alle 13:00 a Londra — un’ora prima. A giugno, entrambi sull’ora estiva, NY EDT (UTC−4) e Londra BST (UTC+1), quindi la riunione è nuovamente alle 14:00 a Londra. Tokyo (UTC+9, senza ora legale) vede la riunione spostarsi tra le 22:00 e le 23:00 a seconda della stagione. Immagina che il team avesse memorizzato la riunione come “14:00 UTC” — il partecipante di NY avrebbe visto l’orario della riunione oscillare avanti e indietro con il cambio dell’ora, e la convenzione “martedì alle 9 di mattina” si sarebbe silenziosamente rotta due volte l’anno.

Quando e perché è importante

I IANA timezone diventano rilevanti nel momento in cui un sistema elabora date relative a più utenti, più luoghi o più stagioni. L’errore da evitare nella memorizzazione è l’uso di offset fissi — “Asia/Karachi” sopravvive a una futura reintroduzione dell’ora legale; “UTC+5” no. L’errore da evitare nella visualizzazione è mostrare timestamp senza specificare il fuso di destinazione — un log di backend che mostra “2026-05-22 14:30” senza tag di fuso è ambiguo e non ricercabile. L’errore da evitare nella logica di business è eseguire aritmetica “aggiungi 1 giorno” in UTC invece che nell’ora locale durante le transizioni dell’ora legale — “giorno successivo alla stessa ora solare” può essere 23 o 25 ore in UTC a seconda che quella notte inizi l’ora legale. Le librerie datetime moderne (l’API Temporal di JavaScript, zoneinfo di Python, java.time di Java) gestiscono correttamente questo quando ricevono identificatori IANA; le API più vecchie (il Date nativo di JavaScript, moment.js senza plugin timezone) producono silenziosamente risposte errate. Riferimento: RFC 6557 — Procedure per la manutenzione del database dei fusi orari.

Il ciclo di rilascio di tzdata IANA:i rilasci di tzdata sono versionati per anno + lettera minuscola — 2024a, 2024b, 2025a, e così via. I rilasci avvengono su richiesta, di solito 4-8 volte all’anno, ogni volta che un governo modifica le regole sull’ora legale o l’offset di fuso di una regione. Cambiamenti recenti degni di nota: il Messico ha abolito l’ora legale a livello nazionale nel 2022; la Russia ha abbandonato e poi ripristinato l’ora invernale permanente in diverse revisioni; il Libano ha avuto un inizio dell’ora legale posticipato di una settimana nel 2023 a causa di una disputa politica. Ogni sistema operativo recepisce le modifiche tramite i normali aggiornamenti dei pacchetti — ma i dispositivi IoT e i vecchi telefoni che non si aggiornano automaticamente possono andare alla deriva, dando origine al classico problema della “sveglia in ritardo di un’ora” durante la prima settimana dopo una variazione alle regole dell’ora legale.

Perché non memorizzare mai gli offset direttamente:l’errore più comune nel codice datetime è memorizzare “UTC+2” invece di Europe/Istanbul. L’offset cattura un fatto puntuale sul fuso ma non le regole. Se la Turchia reintroducesse l’ora legale (l’ha abolita nel 2016, ma le modifiche alle regole sono comuni nella regione), ogni record con “UTC+2” diventerebbe errato da un giorno all’altro. Memorizza l’identificatore IANA e lascia che la consultazione calcoli l’offset corretto per ogni timestamp. Correlati: UTC, secondo intercalare. Riferimento: IANA Time Zone Database.