UTC

UTC(Tempo Coordinato Universale) è lo standard temporale di riferimento globale. Ogni altro fuso orario di uso comune è definito come un offset da UTC — di solito un numero intero di ore, occasionalmente una mezz’ora o un quarto d’ora (l’India è UTC+5:30; il Nepal è UTC+5:45). UTC stesso non osserva l’ora legale.

UTC è mantenuto dall’Ufficio Internazionale dei Pesi e delle Misure (BIPM) e dal Servizio Internazionale di Rotazione della Terra e Sistemi di Riferimento (IERS). La sua frequenza proviene da una media ponderata degli orologi atomici in oltre 80 laboratori nel mondo. Occasionali leap second sono stati inseriti (o, ipoteticamente, rimossi) per mantenere UTC entro 0.9 secondi dal tempo solare. Al 2026 i leap second sono programmati per la deprecazione nel 2035.

UTC viene spesso confuso con GMT(Greenwich Mean Time). Per la maggior parte degli scopi pratici sono identici — entrambi rappresentano l’ora al meridiano di Greenwich senza ora legale. La differenza tecnica è che GMT è definito dalla rotazione della Terra (che è irregolare) e UTC dagli orologi atomici (che sono regolari). Quando il Regno Unito è in orario estivo osserva BST (British Summer Time = UTC+1); GMT non è più usato come etichetta dell’orologio anche se il nome del fuso orario persiste.

Converti tra UTC e uno qualsiasi dei 28 principali fusi orari con il nostro convertitore di fuso orario, che usa il database dei fusi orari IANA del browser per risultati corretti rispetto all’ora legale.

Perché “UTC” invece di CUT o TUC:l’acronimo è un compromesso deliberato. Gli anglofoni volevano “CUT” (Coordinated Universal Time); i francofoni volevano “TUC” (Temps Universel Coordonné). L’ITU e il BIPM si sono accordati su UTC nel 1970 come ordine neutro rispetto alla lingua che non corrisponde esattamente né all’uno né all’altro. La convenzione è di scrivere l’abbreviazione in maiuscolo indipendentemente dall’espansione usata nel testo circostante.

UTC nel codice — cosa memorizzare effettivamente:la regola operativa per qualsiasi sistema che gestisce dati multi-fuso orario è “memorizza in UTC, visualizza in locale”. I timestamp del database appartengono a UTC (PostgreSQL TIMESTAMP WITH TIME ZONE normalizza internamente in UTC; MySQL TIMESTAMP fa lo stesso; MongoDB Dateè UTC per specifica). I layer di visualizzazione convertono alla locale dell’utente al momento del rendering. Memorizzare l’ora locale a parete senza informazioni di zona è la fonte canonica dei bug “la prenotazione si è spostata di un’ora dopo l’ora legale” ed è universalmente considerato un anti-pattern. Riferimento: BIPM — Coordinated Universal Time (UTC).

Esempio pratico

Un utente a New York pianifica una riunione per “le 3:00 PM del 5 novembre 2025”. Il backend dovrebbe memorizzare questo come istante UTC. New York è in EST (UTC−5) il 5 novembre (l’ora legale è terminata il 2 novembre), quindi il valore memorizzato è 2025-11-05T20:00:00Z. Un secondo invitato a Berlino visualizza la stessa riunione: Berlino è in CET (UTC+1) in quella data, quindi il calendario mostra 2025-11-05 21:00 CET. Un terzo invitato a Tokyo (UTC+9, senza ora legale) vede 2025-11-06 05:00 JST — stesso istante, orologi a parete diversi, tutti derivati da un singolo timestamp UTC memorizzato. Supponi ora che la riunione si ripeta settimanalmente: memorizzare “ogni mercoledì alle 20:00 UTC” farebbe slittare silenziosamente l’utente di New York quando termina l’ora legale (si aspettava le 3pm locali, otterrebbe le 4pm locali dopo la transizione del 2 novembre). I sistemi di calendario gestiscono questo memorizzando gli eventi ricorrenti nel fuso orario di origine con il nome del fuso orario IANA allegato, espandendo in UTC solo al rendering.

Quando e perché è importante

Quasi ogni bug “la riunione si è spostata”, “il report è andato all’ora sbagliata” o “il cron job ha eseguito due volte attraverso l’ora legale” si riconduce a memorizzare l’ora locale senza la zona o a memorizzare l’offset della zona (+01:00) invece dell’identificatore della zona (Europe/Berlin). L’offset va bene per un singolo istante ma diventa ambiguo per qualsiasi data futura — l’identificatore della zona preserva le regole dell’ora legale. Le regole pragmatiche: memorizza gli istanti in UTC (o con zona esplicita), memorizza le date rivolte all’utente con identificatori di zona IANA (Europe/Berlin, non +01:00), non usare mai abbreviazioni di zona a 3 lettere (CST è ambiguo tra Cina, Cuba e Stati Uniti centrali), e lascia che un database di zone (tzdata tramite IANA, aggiornato trimestralmente) gestisca la conversione. Riferimento: IANA Time Zone Database.