Aller au contenu principal

5. Format de date et d'heure

Cette section discute des qualités souhaitables des formats de date et d'heure et définit un profil d'ISO 8601 pour une utilisation sur Internet.

5.1. Ordering (Ordonnancement)​

Si les composants de date et d'heure sont ordonnés du moins précis au plus précis, une propriété utile est obtenue. En supposant que les fuseaux horaires des dates et heures sont identiques (par exemple, tous en UTC), exprimés en utilisant la même chaîne (par exemple, tous "Z" ou tous "+00:00"), et que toutes les heures ont le même nombre de chiffres de secondes fractionnaires, alors les chaînes de date et d'heure peuvent être triées comme des chaînes (par exemple, en utilisant la fonction strcmp() en C) et produiront une séquence ordonnée temporellement. La présence de ponctuation optionnelle violerait cette caractéristique.

Exemple :

Ordre correct (année-mois-jour heure:minute:seconde) :
2002-01-15T10:00:00Z
2002-07-20T15:30:00Z
2002-12-31T23:59:59Z

Format incorrect (mois/jour/année) ne peut pas être trié correctement :
01/15/2002 10:00:00
12/31/2002 23:59:59  ← Le tri de chaîne place ceci avant juillet
07/20/2002 15:30:00

5.2. Human Readability (Lisibilité humaine)​

La lisibilité humaine s'est révélée être une caractéristique précieuse des protocoles Internet. Les protocoles lisibles par l'homme réduisent considérablement les coûts de débogage car telnet suffit souvent comme client de test et les analyseurs de réseau n'ont pas besoin d'être modifiés avec la connaissance du protocole. D'autre part, la lisibilité humaine entraîne parfois des problèmes d'interopérabilité.

Exemples de problèmes :

❌ "10/11/1996" est complètement inadapté pour l'échange mondial
   États-Unis : 11 octobre 1996
   Europe : 10 novembre 1996
   
❌ Traduction des abréviations de mois
   Anglais : "Jan", "Feb", "Mar"
   Français : "Jan", "Fév", "Mar"  ← Rompt l'interopérabilité

Parce qu'aucun format de date et d'heure n'est lisible selon les conventions de tous les pays, les clients Internet devraient (SHOULD) être prêts à transformer les dates dans un format d'affichage adapté à la localité. Cela peut inclure la traduction de l'UTC en heure locale.

5.3. Rarely Used Options (Options rarement utilisées)​

Un format qui inclut des options rarement utilisées est susceptible de causer des problèmes d'interopérabilité. C'est parce que les options rarement utilisées sont moins susceptibles d'être utilisées dans les tests alpha ou bêta, donc les bogues d'analyse sont moins susceptibles d'être découverts. Les options rarement utilisées devraient être rendues obligatoires ou omises dans la mesure du possible pour des raisons d'interopérabilité.

Le format défini ci-dessous n'inclut qu'une seule option rarement utilisée : Fractions de seconde (Fractions of a Second). Il est prévu que cela ne sera utilisé que par des applications qui nécessitent un ordonnancement strict des horodatages de date/heure ou qui ont des exigences de précision inhabituelles.

5.4. Redundant Information (Information redondante)​

Si un format de date/heure inclut des informations redondantes, il introduit la possibilité que les informations redondantes ne soient pas corrélées. Par exemple, inclure le jour de la semaine dans un format de date/heure introduit la possibilité que le jour de la semaine soit incorrect mais que la date soit correcte, ou vice versa. Puisqu'il n'est pas difficile de calculer le jour de la semaine à partir de la date (voir Annexe B), le jour de la semaine ne devrait pas être inclus dans un format de date/heure.

Exemple de problème :

❌ "Monday, 2002-07-16T10:00:00Z"
   Problème : Le 16 juillet 2002 est en fait un mardi, pas un lundi
   Si le jour et la date ne correspondent pas, lequel faut-il faire confiance ?

✅ "2002-07-16T10:00:00Z"
   Solution : Omettre le jour de la semaine, calculer si nécessaire

5.5. Simplicity (Simplicité)​

L'ensemble complet des formats de date et d'heure spécifiés dans ISO 8601 [ISO8601] est assez complexe dans une tentative de fournir plusieurs représentations et représentations partielles. L'Annexe A contient une tentative de traduire la syntaxe complète d'ISO 8601 en ABNF. Les protocoles Internet ont des exigences quelque peu différentes et la simplicité s'est révélée être une caractéristique importante. De plus, les protocoles Internet ont généralement besoin d'une spécification complète des données pour atteindre une véritable interopérabilité. Par conséquent, la syntaxe complète d'ISO 8601 est jugée trop complexe pour la plupart des protocoles Internet.

La section suivante définit un profil d'ISO 8601 pour une utilisation sur Internet. C'est un sous-ensemble cohérent du format étendu ISO 8601. La simplicité est obtenue en rendant la plupart des champs et de la ponctuation obligatoires.

5.6. Internet Date/Time Format (Format de date/heure Internet)​

Le profil suivant des dates ISO 8601 [ISO8601] devrait (SHOULD) être utilisé dans les nouveaux protocoles sur Internet. Ceci est spécifié en utilisant la notation de description de syntaxe définie dans [ABNF].

Définition de la syntaxe 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

Notes importantes​

Sensibilité à la casse : Selon [ABNF] et ISO8601, les caractères "T" et "Z" dans cette syntaxe peuvent également être respectivement en minuscules "t" ou "z".

Les spécifications qui utilisent ce format dans des environnements où la casse est significative (comme XML) peuvent (MAY) restreindre davantage la syntaxe de date/heure de sorte que les lettres 'T' et 'Z' utilisées dans la syntaxe de date/heure doivent toujours être en majuscules. Les applications qui génèrent ce format devraient (SHOULD) utiliser des lettres majuscules.

Délimiteurs : ISO 8601 définit la date et l'heure séparées par "T". Les applications utilisant cette syntaxe peuvent (MAY) choisir, pour des raisons de lisibilité, de spécifier un full-date et un full-time séparés par (par exemple) un caractère espace.

Exemples de format​

Format 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

Avec secondes fractionnaires :
2002-07-15T10:30:00.123456Z
2002-07-15T10:30:00.52Z

Variantes lisibles (non standard mais autorisées) :
2002-07-15 10:30:00Z
2002-07-15t10:30:00z

5.7. Restrictions​

L'élément grammatical date-mday représente le numéro de jour dans le mois actuel. La valeur maximale varie en fonction du mois et de l'année :

Numéro de moisMois/AnnéeMaximum date-mday
01Janvier (January)31
02Février, normal (February, normal)28
02Février, année bissextile (February, leap year)29
03Mars (March)31
04Avril (April)30
05Mai (May)31
06Juin (June)30
07Juillet (July)31
08Août (August)31
09Septembre (September)30
10Octobre (October)31
11Novembre (November)30
12Décembre (December)31

Secondes intercalaires​

L'élément grammatical time-second peut (MAY) avoir la valeur "60" à la fin des mois au cours desquels une seconde intercalaire se produit. Les secondes intercalaires sont utilisées pour maintenir l'UTC proche du temps de rotation de la Terre. Voir l'Annexe D pour plus d'informations sur les secondes intercalaires.

Exemples de secondes intercalaires :

1990-12-31T23:59:60Z  ✅ Valide (seconde intercalaire le 31 décembre 1990)
1990-12-31T23:59:61Z  ❌ Invalide (maximum est 60)
1990-06-15T23:59:60Z  ❌ Invalide (secondes intercalaires uniquement en fin de mois)

5.8. Examples (Exemples)​

Voici quelques exemples d'horodatages de date/heure RFC 3339 valides :

1985-04-12T23:20:50.52Z
  Représente : 12 avril 1985, 23:20:50.52 UTC

1996-12-19T16:39:57-08:00
  Représente : 19 décembre 1996, 16:39:57 Heure du Pacifique (PST)
  UTC équivalent : 1996-12-20T00:39:57Z

1990-12-31T23:59:60Z
  Représente : Seconde intercalaire le 31 décembre 1990

1990-12-31T15:59:60-08:00
  Représente : Seconde intercalaire le 31 décembre 1990 en PST
  UTC équivalent : 1990-12-31T23:59:60Z

1937-01-01T12:00:27.87+00:20
  Représente : 1er janvier 1937, 12:00:27.87, UTC+00:20
  (Exemple de fuseau horaire historique)

Exemples invalides​

❌ 1985-04-12  (heure manquante)
❌ 23:20:50.52Z  (date manquante)
❌ 1985-04-12 23:20:50.52Z  (devrait utiliser 'T' pas espace, bien que certaines implémentations l'autorisent)
❌ 1985-04-32T23:20:50.52Z  (date invalide : avril n'a pas de 32e jour)
❌ 1985-02-29T23:20:50.52Z  (date invalide : 1985 n'est pas une année bissextile)

Recommandation d'implémentation : Toujours générer le format standard (en utilisant le délimiteur 'T' et 'Z' en majuscule), mais analyser de manière libérale (accepter 't', 'z' et éventuellement les délimiteurs d'espace).

Dernière mise à jour le