Formato data e ora ISO 8601 spiegato
ISO 8601 è lo standard internazionale per rappresentare date e ore come stringhe. La sua forma canonica — 2024-03-15T14:30:00Z — è inequivocabile, ordinabile e supportata in ogni linguaggio e database moderno. Questa guida copre il formato componente per componente, il sottoinsieme RFC 3339 che la maggior parte delle API usa davvero, la più recente estensione di fuso RFC 9557, e le varianti per durate, intervalli e date settimanali.
Che cos'è ISO 8601?
ISO 8601 è la rappresentazione di date e ore dell'Organizzazione internazionale per la normazione. La versione attuale (ISO 8601-1:2019 / -2:2019) definisce un formato di testo compatto, ordinato e neutro rispetto alla lingua. Il suo intero scopo è eliminare l'ambiguità: una data come 03/04/2024 è il 4 marzo negli USA e il 3 aprile in gran parte d'Europa, ma 2024-03-04 significa la stessa cosa ovunque. Lo standard è anche la base di RFC 3339, il profilo che la maggior parte dei protocolli internet usa davvero.
- Ordine anno-mese-giorno, sempre: 2024-03-15 (non 03/15/2024 né 15/03/2024)
- Parte oraria separata da una T letterale o uno spazio: 2024-03-15T14:30:00
- Fuso esplicito: Z per UTC, oppure ±HH:MM per un offset
- Ordinabile come testo — l'ordine lessicografico coincide con quello cronologico
Il formato canonico di data-ora
La forma più comune assomiglia a 2024-03-15T14:30:00.123Z. Ogni componente è di larghezza fissa e con zeri iniziali, ed è questo che rende il formato ordinabile e inequivocabile.
| Componente | Esempio | Significato |
|---|---|---|
| YYYY | 2024 | Anno a quattro cifre |
| MM | 03 | Mese a due cifre (01–12) |
| DD | 15 | Giorno a due cifre (01–31) |
| T | T | Separatore data/ora (RFC 3339 consente anche uno spazio) |
| hh:mm:ss | 14:30:00 | Ora su 24 h, con zeri iniziali |
| .fff | .123 | Secondi frazionari opzionali (precisione arbitraria in ISO 8601) |
| Z o ±hh:mm | Z | Designatore di fuso (Z = UTC = +00:00) |
Designatori di fuso orario
I fusi di ISO 8601 sono codificati come offset rispetto a UTC, mai come abbreviazioni di fuso tipo EST o CET (che sono ambigue). La stringa porta informazioni sufficienti a ricostruire l'istante UTC esatto, inclusi gli offset di mezz'ora e di 45 minuti che alcune regioni usano.
| Designatore | Offset da UTC | Fuso di esempio |
|---|---|---|
| Z | +00:00 | UTC (ora "Zulu") |
| +09:00 | 9 ore avanti | Ora standard del Giappone |
| -05:00 | 5 ore indietro | Ora standard orientale (USA) |
| +05:30 | 5,5 ore avanti | Ora standard dell'India |
| +05:45 | 5,75 ore avanti | Ora standard del Nepal |
| (nessuno) | non specificato | Ora locale — ambigua; da evitare nelle API |
ISO 8601 vs RFC 3339
RFC 3339 è un profilo di ISO 8601 — più restrittivo e più facile da analizzare. La maggior parte dei protocolli internet (API JSON, HTTP, specifiche IETF) mira specificamente a RFC 3339, quindi quando un'API dice "ISO 8601" intende quasi sempre il sottoinsieme RFC 3339. Le differenze sono piccole ma decidono se una data stringa viene analizzata.
| Caratteristica | ISO 8601 | RFC 3339 |
|---|---|---|
| Separatore data/ora | T, oppure omesso nel formato base | T o un singolo spazio (obbligatorio) |
| Offset di fuso | Opzionale | Obbligatorio |
| Secondi frazionari | Precisione arbitraria | Consentiti, limitati dal parser |
| Formato base (senza trattini) | 20240315T143000Z consentito | Non consentito |
| Date settimanali/ordinali | Consentite | Non consentite |
| Uso tipico | Archivi, fogli di calcolo, interscambio | API JSON, HTTP, specifiche IETF |
RFC 9557: i fusi e l'estensione Temporal
Un semplice offset come +01:00 ti dice l'istante ma non il fuso — e gli offset cambiano con l'ora legale, quindi lo stesso fuso è +01:00 d'inverno e +02:00 d'estate. RFC 9557 (2024) colma questa lacuna con l'Internet Extended Date/Time Format (IXDTF): aggiunge il nome del fuso IANA tra parentesi quadre, come in 2024-03-15T14:30:00+01:00[Europe/Paris]. È il formato stringa che l'API Temporal di JavaScript legge e scrive, quindi lo vedrai sempre più man mano che l'adozione di Temporal cresce. Resta retrocompatibile — rimuovi il suffisso tra parentesi e hai un normale timestamp RFC 3339.
- Solo offset: 2024-03-15T14:30:00+01:00 — l'istante, ma non il fuso
- IXDTF (RFC 9557): 2024-03-15T14:30:00+01:00[Europe/Paris] — istante più fuso
- Retrocompatibile: l'etichetta tra parentesi è ignorabile dai parser RFC 3339
Varianti: durate, intervalli, date settimanali
ISO 8601 copre più dei semplici istanti. Diverse varianti compaiono regolarmente nei sistemi di pianificazione, archiviazione e reportistica:
- Durate: P3Y6M4DT12H30M5S = 3 anni, 6 mesi, 4 giorni, 12 ore, 30 minuti, 5 secondi
- Intervalli: 2024-01-01/2024-02-01, oppure 2024-01-01/P1M (inizio + durata)
- Date ordinali: 2024-075 = il 75° giorno del 2024 (15 marzo)
- Date settimanali: 2024-W11-5 = venerdì della settimana ISO 11 del 2024
- Intervalli ripetuti: R3/2024-01-01/P1D = tre intervalli di un giorno a partire dal 1° gennaio
ISO 8601 nel codice
Ogni linguaggio diffuso può produrre e analizzare il sottoinsieme RFC 3339 da subito. L'abitudine più sicura è emettere in UTC con una Z e rianalizzare verso un istante, lasciando ogni conversione di fuso al livello di presentazione.
- JavaScript emettere: new Date().toISOString() // '2024-03-15T14:30:00.123Z'
- JavaScript analizzare: new Date('2024-03-15T14:30:00Z') // sottoinsieme RFC 3339
- Python emettere: datetime.now(timezone.utc).isoformat()
- Python analizzare: datetime.fromisoformat('2024-03-15T14:30:00+00:00') // ISO completo in 3.11+
- La maggior parte dei database (Postgres, SQLite) accetta e restituisce ISO 8601 timestamptz direttamente
Errori comuni in ISO 8601
Anche con uno standard rigoroso, il codice di parsing ed emissione commette la stessa manciata di errori:
- Omettere il fuso: 2024-03-15T14:30:00 senza Z né offset è ambiguo
- Usare "+0000" invece di "+00:00" — alcuni parser lo accettano, RFC 3339 no
- Usare una T non-lettera (i sosia Unicode si copiano male)
- Mischiare AM/PM su 12 h in ISO 8601 — è sempre su 24 h
- Troncare i secondi frazionari senza arrotondare — scegli una precisione e mantienila
- Trattare ISO 8601 come dipendente dalla locale — non lo è; il formato è fisso a prescindere dalla lingua
Riferimenti correlati
FAQ
- "2024-03-15 14:30:00Z" è ISO 8601 valido?
- Sì — lo spazio tra data e ora è consentito in ISO 8601 (e in RFC 3339). La forma con T è preferibile per un parsing automatico inequivocabile.
- Cosa significa la Z alla fine?
- Z significa UTC (offset +00:00). È l'abbreviazione di "ora Zulu", l'alfabeto fonetico NATO/aviazione per la lettera Z.
- Come faccio il parsing di ISO 8601 in JavaScript?
- new Date("2024-03-15T14:30:00Z") funziona per il sottoinsieme RFC 3339 standard. Per un supporto ISO 8601 più ampio, usa una libreria come date-fns o l'API Temporal.
- ISO 8601 è la stessa cosa di RFC 3339?
- No — RFC 3339 è un sottoinsieme rigoroso. Ogni timestamp RFC 3339 è ISO 8601 valido, ma non ogni timestamp ISO 8601 è RFC 3339 valido.
- Che cos'è RFC 9557?
- RFC 9557 (2024) estende RFC 3339 con l'Internet Extended Date/Time Format (IXDTF). Aggiunge il nome del fuso IANA tra parentesi quadre — per esempio 2024-03-15T14:30:00+01:00[Europe/Paris] — ed è alla base del formato stringa usato dall'API Temporal di JavaScript.
- Il separatore T è obbligatorio?
- In ISO 8601 rigoroso la T può essere omessa nel formato base; RFC 3339 richiede una T o un singolo spazio. Per il parsing automatico, includi sempre la T.
- Qual è la differenza tra ISO 8601 e ISO 8601-2?
- ISO 8601-1 copre la rappresentazione base di date e ore. ISO 8601-2 (l'estensione del 2019) aggiunge nuovi costrutti come date incerte, valori qualificanti e intervalli complessi.