Passa al contenuto principale

5. Formato data e ora

Questa sezione discute le qualità desiderabili dei formati di data e ora e definisce un profilo di ISO 8601 per l'uso su Internet.

5.1. Ordering (Ordinamento)​

Se i componenti di data e ora sono ordinati dal meno preciso al più preciso, si ottiene una proprietà utile. Supponendo che i fusi orari delle date e degli orari siano gli stessi (ad esempio, tutti in UTC), espressi usando la stessa stringa (ad esempio, tutti "Z" o tutti "+00:00"), e che tutti gli orari abbiano lo stesso numero di cifre di secondi frazionari, allora le stringhe di data e ora possono essere ordinate come stringhe (ad esempio, utilizzando la funzione strcmp() in C) e produrranno una sequenza ordinata temporalmente. La presenza di punteggiatura opzionale violerebbe questa caratteristica.

Esempio:

Ordinamento corretto (anno-mese-giorno ora:minuto:secondo):
2002-01-15T10:00:00Z
2002-07-20T15:30:00Z
2002-12-31T23:59:59Z

Formato errato (mese/giorno/anno) non può essere ordinato correttamente:
01/15/2002 10:00:00
12/31/2002 23:59:59  ← L'ordinamento di stringa pone questo prima di luglio
07/20/2002 15:30:00

5.2. Human Readability (Leggibilità umana)​

La leggibilità umana si è dimostrata una caratteristica preziosa dei protocolli Internet. I protocolli leggibili dall'uomo riducono notevolmente i costi di debug poiché telnet è spesso sufficiente come client di test e gli analizzatori di rete non devono essere modificati con la conoscenza del protocollo. D'altra parte, la leggibilità umana a volte porta a problemi di interoperabilità.

Esempi di problemi:

❌ "10/11/1996" è completamente inadatto per lo scambio globale
   USA: 11 ottobre 1996
   Europa: 10 novembre 1996
   
❌ Traduzione delle abbreviazioni dei mesi
   Inglese: "Jan", "Feb", "Mar"
   Francese: "Jan", "Fév", "Mar"  ← Rompe l'interoperabilità

Poiché nessun formato di data e ora è leggibile secondo le convenzioni di tutti i paesi, i client Internet dovrebbero (SHOULD) essere preparati a trasformare le date in un formato di visualizzazione adatto alla località. Ciò può includere la traduzione dell'UTC in ora locale.

5.3. Rarely Used Options (Opzioni raramente utilizzate)​

Un formato che include opzioni raramente utilizzate è probabile che causi problemi di interoperabilità. Questo perché le opzioni raramente utilizzate sono meno probabili da essere utilizzate nei test alpha o beta, quindi è meno probabile che vengano scoperti bug nell'analisi. Le opzioni raramente utilizzate dovrebbero essere rese obbligatorie o omesse per quanto possibile per motivi di interoperabilità.

Il formato definito di seguito include solo un'opzione raramente utilizzata: Frazioni di secondo (Fractions of a Second). Si prevede che questo sarà utilizzato solo da applicazioni che richiedono un ordinamento rigoroso dei timestamp di data/ora o che hanno requisiti di precisione insoliti.

5.4. Redundant Information (Informazioni ridondanti)​

Se un formato di data/ora include informazioni ridondanti, introduce la possibilità che le informazioni ridondanti non siano correlate. Ad esempio, includere il giorno della settimana in un formato di data/ora introduce la possibilità che il giorno della settimana sia errato ma la data sia corretta, o viceversa. Poiché non è difficile calcolare il giorno della settimana dalla data (vedere Appendice B), il giorno della settimana non dovrebbe essere incluso in un formato di data/ora.

Esempio di problema:

❌ "Monday, 2002-07-16T10:00:00Z"
   Problema: Il 16 luglio 2002 è in realtà un martedì, non un lunedì
   Se il giorno e la data non corrispondono, quale dovrebbe essere attendibile?

✅ "2002-07-16T10:00:00Z"
   Soluzione: Omettere il giorno della settimana, calcolare se necessario

5.5. Simplicity (Semplicità)​

Il set completo di formati di data e ora specificati in ISO 8601 [ISO8601] è piuttosto complesso nel tentativo di fornire più rappresentazioni e rappresentazioni parziali. L'Appendice A contiene un tentativo di tradurre la sintassi completa di ISO 8601 in ABNF. I protocolli Internet hanno requisiti un po' diversi e la semplicità si è dimostrata una caratteristica importante. Inoltre, i protocolli Internet di solito necessitano di una specifica completa dei dati per ottenere una vera interoperabilità. Pertanto, la sintassi completa di ISO 8601 è ritenuta troppo complessa per la maggior parte dei protocolli Internet.

La sezione seguente definisce un profilo di ISO 8601 per l'uso su Internet. È un sottoinsieme coerente del formato esteso ISO 8601. La semplicità è ottenuta rendendo obbligatori la maggior parte dei campi e della punteggiatura.

5.6. Internet Date/Time Format (Formato data/ora Internet)​

Il seguente profilo delle date ISO 8601 [ISO8601] dovrebbe (SHOULD) essere utilizzato nei nuovi protocolli su Internet. Questo è specificato utilizzando la notazione di descrizione della sintassi definita in [ABNF].

Definizione della sintassi ABNF​

date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

Note importanti​

Sensibilità alle maiuscole/minuscole: Secondo [ABNF] e ISO8601, i caratteri "T" e "Z" in questa sintassi possono alternativamente essere rispettivamente in minuscolo "t" o "z".

Le specifiche che utilizzano questo formato in ambienti dove la distinzione tra maiuscole e minuscole è significativa (come XML) possono (MAY) limitare ulteriormente la sintassi di data/ora in modo che le lettere 'T' e 'Z' utilizzate nella sintassi di data/ora debbano essere sempre maiuscole. Le applicazioni che generano questo formato dovrebbero (SHOULD) utilizzare lettere maiuscole.

Delimitatori: ISO 8601 definisce data e ora separati da "T". Le applicazioni che utilizzano questa sintassi possono (MAY) scegliere, per motivi di leggibilità, di specificare un full-date e full-time separati da (ad esempio) un carattere spazio.

Esempi di formato​

Formato standard:
2002-07-15T10:30:00Z
2002-07-15T10:30:00.123Z
2002-07-15T10:30:00+08:00
2002-07-15T10:30:00-04:00

Con secondi frazionari:
2002-07-15T10:30:00.123456Z
2002-07-15T10:30:00.52Z

Varianti leggibili (non standard ma consentite):
2002-07-15 10:30:00Z
2002-07-15t10:30:00z

5.7. Restrictions (Restrizioni)​

L'elemento grammaticale date-mday rappresenta il numero del giorno all'interno del mese corrente. Il valore massimo varia in base al mese e all'anno:

Numero meseMese/AnnoMassimo date-mday
01Gennaio (January)31
02Febbraio, normale (February, normal)28
02Febbraio, anno bisestile (February, leap year)29
03Marzo (March)31
04Aprile (April)30
05Maggio (May)31
06Giugno (June)30
07Luglio (July)31
08Agosto (August)31
09Settembre (September)30
10Ottobre (October)31
11Novembre (November)30
12Dicembre (December)31

Secondi intercalari​

L'elemento grammaticale time-second può (MAY) avere il valore "60" alla fine dei mesi in cui si verifica un secondo intercalare. I secondi intercalari sono utilizzati per mantenere l'UTC vicino al tempo di rotazione della Terra. Vedere l'Appendice D per ulteriori informazioni sui secondi intercalari.

Esempi di secondi intercalari:

1990-12-31T23:59:60Z  ✅ Valido (secondo intercalare il 31 dicembre 1990)
1990-12-31T23:59:61Z  ❌ Non valido (massimo è 60)
1990-06-15T23:59:60Z  ❌ Non valido (secondi intercalari solo a fine mese)

5.8. Examples (Esempi)​

Ecco alcuni esempi di timestamp di data/ora RFC 3339 validi:

1985-04-12T23:20:50.52Z
  Rappresenta: 12 aprile 1985, 23:20:50.52 UTC

1996-12-19T16:39:57-08:00
  Rappresenta: 19 dicembre 1996, 16:39:57 Pacific Standard Time (PST)
  UTC equivalente: 1996-12-20T00:39:57Z

1990-12-31T23:59:60Z
  Rappresenta: Secondo intercalare il 31 dicembre 1990

1990-12-31T15:59:60-08:00
  Rappresenta: Secondo intercalare il 31 dicembre 1990 in PST
  UTC equivalente: 1990-12-31T23:59:60Z

1937-01-01T12:00:27.87+00:20
  Rappresenta: 1 gennaio 1937, 12:00:27.87, UTC+00:20
  (Esempio di fuso orario storico)

Esempi non validi​

❌ 1985-04-12  (ora mancante)
❌ 23:20:50.52Z  (data mancante)
❌ 1985-04-12 23:20:50.52Z  (dovrebbe usare 'T' non spazio, sebbene alcune implementazioni lo consentano)
❌ 1985-04-32T23:20:50.52Z  (data non valida: aprile non ha il 32° giorno)
❌ 1985-02-29T23:20:50.52Z  (data non valida: il 1985 non è un anno bisestile)

Raccomandazione per l'implementazione: Generare sempre il formato standard (utilizzando il delimitatore 'T' e 'Z' maiuscolo), ma analizzare in modo liberale (accettare 't', 'z' e possibilmente delimitatori di spazio).

Ultimo aggiornamento il