Groupe de travail Réseau	G. Klyne, Clearswift Corporation	
Request for Comments : 3339	C. Newman, Sun Microsystems	
Catégorie : En cours de normalisation	juillet 2002	
Traduction Claude Brière de L'Isle		

Date et heure sur l'Internet : horodatages

Statut du présent mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l'Internet. Il appelle à la discussion et à des suggestions pour son amélioration. Prière de se référer à l'édition actuelle des "Normes Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright 
Copyright (C) The Internet Society (2002). T

Résumé
Le présent document définit un format de date et d'heure à utiliser dans les protocoles de l'Internet, qui est un profil de la norme ISO 8601 pour la représentation des dates et de l'heure en utilisant le calendrier grégorien.

Table des Matières
1. Introduction	1
2. Définitions	2
3. Année à deux chiffres	2
4. Heure locale	3
4.1 Heure universelle coordonnée (UTC)	3
4.2 Décalages locaux	3
4.3 Convention inconnue de décalage local	3
4.4 Heure locale non qualifiée	3
5. Format de date et d'heure	4
5.1 Ordre	4
5.2 Lisibilité par l'homme	4
5.3 Options rarement utilisées	4
5.4 Informations redondantes	4
5.5 Simplicité	5
5.6 Format de date/heure de l'Internet	5
5.7 Restrictions	5
5.8 Exemples	6
6. Références	6
7. Considérations pour la sécurité	7
Appendice A ABNF de la norme ISO 8601	7
Appendice B. Jour de la semaine	9
Appendice C Années bisextiles	9
Appendice D  Secondes sautées	9
Remerciements	10
Adresse des auteurs	10
Déclaration complète de droits de reproduction	10

1.	Introduction

Les formats de date et d'heure causent une certaine confusion et des problèmes d'interopérabilité dans l'Internet. Le présent document vise la plupart des problèmes rencontrés et fait des recommandations pour améliorer la cohérence et l'interopérabilité lors de la représentation et de l'utilisation de la date et de l'heure dans les protocoles de l'Internet.

Le présent document inclut un profil Internet de la norme [ISO8601] pour la représentation des dates et des heures dans le calendrier grégorien.

Il y a de nombreuses façon de faire paraître les valeurs de date et d'heure dans les protocoles de l'Internet : le présent document se concentre sur un seul usage courant, à savoir les horodatages dans les événements de protocoles de l'Internet. Cet objectif limité a les conséquences suivantes :

o	Toutes les dates et heures sont supposées être dans "l'ère actuelle", quelque part entre 0000AD et 9999AD.

o	Toutes les heures sont exprimées en relation déclarée (décalage) avec le temps universel coordonné (UTC). (Ceci est distinct de certains usages d'applications de programmation où une heure locale et une localisation peuvent être connues, mais où la relation réelle avec l'UTC peut dépendre de l'action connue ou inconnue de politiques ou d'administrateurs. L'heure UTC correspondant à 17:00 le 23 mars 2005 à New York peut dépendre de décisions administratives sur l'heure d'été. La présente spécification évite totalement de telles considérations.)

o	Les horodatages peuvent exprimer des heures qui sont intervenues avant l'introduction de l'UTC. De tels horodatages sont exprimés par rapport au temps universel, en appliquant la meilleure pratique disponible à l'heure déclarée.

o	Les expressions de date et d'heure indiquent un instant dans le temps. La description de périodes de temps, ou d'intervalles, n'est pas traitée ici.

2.	Définitions

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119].

UTC	Temps universel coordonné tel que conservé par le Bureau International des Poids et Mesures (BIPM).

seconde	Unité de base de la mesure du temps dans le système d'unités international. Elle est définie comme la durée de 9  192  631  770 cycles d'une onde de lumière absorbée ou émise par la transition hyperfine des atomes de césium  133 dans leur état naturel non perturbé par des champs externes.

minute	Une durée de 60 secondes. Cependant, voir aussi les restrictions du paragraphe 5.7 et de l'Appendice D pour la façon dont les secondes sautées sont notées dans les minutes.

heure	Une période de 60 minutes.

jour	Une période de 24 heures.

année bissextile	Dans le calendrier grégorien, c'est une année qui a 366 jours. Une année bissextile est une année dont le nombre est divisible par quatre un nombre entier de fois, sauf si c'est un siècle (c'est à dire divisible par cent) où elle doit aussi être divisible par quatre cents un nombre entier de fois.

ABNF	Forme Backus-Naur augmentée, un format utilisé pour représenter les chaînes permises dans un protocole ou langage, comme défini dans [ABNF].

Format de date/heure de messagerie	Format de date/heure utilisé par la messagerie Internet comme défini par la [RFC2822].

Format de date/heure de l'Internet	Le format de date défini à la section 5 de ce document.

Horodatage	Ce terme est utilisé dans ce document pour se référer à une représentation non ambiguë d'un instant.

Z	Suffixe qui, lorsque appliqué à une heure, note un décalage UTC de 00:00 ; souvent prononcé "Zulu" de la représentation de l'alphabet phonétique ICAO de la lettre "Z".

Pour plus d'informations sur les échelles de temps, voir l'appendice E de [NTP], la Section 3 de [ISO8601], et les documents appropriés de l'UIT [ITU-R-TF].

3.	Année à deux chiffres

Les exigences suivantes s'appliquent au problème de l'ambiguïté des années à deux chiffres :

o	Les protocoles Internet DOIVENT générer des années à quatre chiffres dans les dates.

o	L'utilisation d'années à deux chiffres est déconseillé. Si une année à deux chiffres est reçue, elle ne devrait être acceptée QUE SI une interprétation incorrecte ne causera pas de défaillance du protocole ou du traitement (par exemple, si elle n'est utilisée que pour les besoins de la connexion ou du traçage).

o	Il est possible qu'un programme utilisant des années à deux chiffres représente des années après 1999 avec trois chiffres. Cela arrive si le programme soustrait simplement 1900 de l'année et ne vérifie pas le nombre de chiffres. Les programmes qui souhaitent un traitement robuste des dates générées par de tels logiciels peuvent ajouter 1900 aux années à trois chiffres.

o	Il est possible qu'un programme qui utilise des années à deux chiffres représente les années après 1999 comme ":0", ":1", ... ":9", ";0", ... Cela arrive si le programme retranche simplement 1900 de l'année et ajoute la décade au caractère zéro US-ASCI. Les programmes qui souhaitent une représentation robuste des dates générées par de tels logiciels devraient détecter les décades non numériques et les interpréter de façon appropriée.

Les problèmes avec les années à deux chiffres démontrent amplement pourquoi toutes les dates et heures utilisées dans les protocoles Internet DOIVENT être pleinement qualifiées.

4.	Heure locale
4.1	Heure universelle coordonnée (UTC)

Parce que les règles de passage à l'heure d'été pour les zones horaires locales sont très embrouillées et peuvent changer sur la base de règles locales à des moments imprévisibles, l'interopérabilité est mieux réalisée en utilisant l'heure universelle coordonnée (UTC). La présente spécification ne s'occupe pas des règles des zones horaires locales.

4.2	Décalages locaux

Le décalage entre l'heure locale et l'UTC est souvent une information utile. Par exemple, en messagerie électronique [RFC2822] le décalage local fournit une heuristique utile pour déterminer la probabilité d'une prompte réponse. Les tentatives de marquage des décalages locaux avec des chaînes alphabétiques ont donnée de mauvais résultats pour l'interopérabilité dans le passé [IMAIL], [HOST-REQ]. Par suite, la [RFC2822] a rendu obligatoires les décalages numériques.

Les décalages numériques sont calculés comme de "l'heure locale moins UTC". De sorte que l'heure équivalente en UTC peut être déterminée en retranchant le décalage de l'heure locale. Par exemple, 18:50:00-04:00 est la même heure que 22:50:00Z. (Cet exemple montre des décalages négatifs traités en ajoutant la valeur absolue du décalage.)

NOTE : Suivant la norme ISO 8601, les décalages numériques ne représentent que les zones horaires qui diffèrent de l'UTC par un nombre entier de minutes. Cependant, de nombreuses zones horaires historiques diffèrent de l'UTC d'un nombre non entier de minutes. Pour représenter exactement de tels horodatages historiques, les applications doivent les convertir en une zone horaire représentable.

4.3	Convention inconnue de décalage local

Si l'heure UTC est connue, mais si le décalage avec l'heure locale est inconnu, cela peut être représenté avec un décalage de "-00:00". Cela diffère sémantiquement d'un décalage de "Z" ou "+00:00", qui implique que l'UTC est le point de référence préféré pour l'heure spécifiée. La [RFC2822] décrit une convention similaire pour la messagerie électronique.

4.4	Heure locale non qualifiée

Un certain nombre d'appareils actuellement connectés à l'Internet font tourner leurs horloges internes en heure locale et ignorent l'UTC. Bien que l'Internet se fasse une tradition d'accepter la réalité lors de la création de spécifications, cela ne devrait pas être fait aux dépens de l'interopérabilité. Dans la mesure où l'interprétation d'une zone horaire locale non qualifiée va échouer dans approximativement 23/24 du globe, les problèmes d'interopérabilité d'heure locale non qualifiée sont réputés inacceptables pour l'Internet. Les systèmes qui sont configurés avec une heure locale, qui ignorent l'UTC correspondant, et dépendent de la synchronisation horaire avec les autres systèmes Internet, DOIVENT utiliser un mécanisme qui assure une synchronisation correcte avec l'UTC. Certains des mécanismes convenables sont :

o	L'utilisation du Protocole de l'heure du réseau [NTP] pour obtenir l'heure en UTC.

o	L'utilisation d'un autre hôte dans la même zone horaire locale comme passerelle vers l'Internet. Cet hôte DOIT corriger les heures locales non qualifiées qui sont transmises aux autres hôtes.

o	Inciter l'usager à faire les réglages de zone horaire locale et de règles de passage à l'heure d'été.

5.	Format de date et d'heure

Cette section expose les qualités souhaitables des formats de date et d'heure et définit un profil de la norme ISO 8601 à utiliser dans les protocoles de l'Internet.

5.1	Ordre

Si les composant de date et d'heure sont ordonnés du moins précis au plus précis, une propriété utile est réalisée. En supposant que les zones horaires des dates et des heures sont les mêmes (par exemple, toutes en UTC) et exprimées en utilisant la même chaîne (par exemple, toutes "Z" ou toutes "+00:00"), et que toutes les heures ont le même nombre de chiffres de fraction de secondes, les chaînes de date et d'heure peuvent alors être triées comme chaînes (par exemple, en utilisant la fonction strcmp() dans C) et il va en résulter une séquence ordonnée selon l'heure. La présence d'une ponctuation facultative violerait cette caractéristique.

5.2	Lisibilité par l'homme

La lisibilité par l'homme s'est révélé un dispositif précieux des protocoles de l'Internet. Les protocoles lisibles par l'homme réduisent considérablement les coûts de débogage car telnet suffit souvent comme client d'essai et les analyseurs de réseau n'ont pas besoin d'être modifiés avec la connaissance du protocole. D'un autre côté, la lisibilité par l'homme débouche parfois sur des problèmes d'interopérabilité. Par exemple, le format de date "10/11/1996" est complètement inutilisable pour les échanges mondiaux parce qu'il est interprété différemment dans les différents pays. De plus, le format de date qui est dans [IMAIL] a causé des problèmes d'interopérabilité lorsque des gens ont supposé que toute chaîne de texte était permise et traduisait les abréviations de trois lettres en d'autres langues ou substituaient les formats de date qui étaient les plus faciles à générer (par exemple, le format utilisé par la fonction ctime du langage C). Pour cette raison, on doit trouver un équilibre entre la lisibilité humaine et l'interopérabilité.

Comme aucun format de date et d'heure n'est lisible selon les conventions de tous les pays, les clients Internet DEVRAIENT être prêts à transformer les dates en un format d'affichage convenable pour le local. Cela peut inclure de traduire l'UTC en heure locale.

5.3	Options rarement utilisées

Un format qui comporte des options rarement utilisées va vraisemblablement causer des problèmes d'interopérabilité. Cela parce que les options rarement utilisées vont vraisemblablement être moins utilisées pour les essais en alpha ou beta, de sorte que les bogues ont moins de chances d'être découvertes à l'analyse. Les options rarement utilisées devraient être rendues obligatoires ou omises chaque fois que possible au nom de l'interopérabilité.

Le format défini ci-dessous comporte seulement une option rarement utilisée : celle des fractions de seconde. On pense que ce ne sera utilisé que par des applications qui exigent un ordre strict des horodatages ou qui ont une exigence de précision hors du commun.

5.4	Informations redondantes

Si un format de date/heure comporte des informations redondantes, cela 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. Comme il n'est pas difficile de calculer le jour de la semaine à partir d'une date (voir l'Appendice B), le jour de la semaine ne devrait pas être inclus dans un format de date/heure.

5.5	Simplicité

L'ensemble complet des formats de date et d'heure spécifié dans la norme [ISO8601] est assez complexe car il essaye de fournir plusieurs représentations et des représentations partielles. L'Appendice A contient un essai de traduction de la syntaxe complète de la norme ISO 8601 en ABNF. Les protocoles de l'Internet ont des exigences assez différentes et la simplicité s'est révélée être une caractéristique importante. De plus, les protocoles de l'Internet ont généralement besoin d'une spécification complète des données afin de réaliser une véritable interopérabilité. Donc, la grammaire complète de ISO 8601 est réputée trop complexe pour la plupart des protocoles de l'Internet.

Le paragraphe suivant définit un profil de la norme ISO 8601 pour l'usage de l'Internet. C'est un sous ensemble conforme du format étendu de la norme ISO 8601. La simplicité est réalisée en rendant la plupart des champs et de la ponctuation obligatoires.

5.6	Format de date/heure de l'Internet

Le profil suivant des dates de la norme [ISO8601] DEVRAIT être utilisé dans les nouveaux protocoles de l'Internet. Il est spécifié en utilisant la notation de description de la syntaxe définie dans [ABNF].

date-année	= 4CHIFFRES
date-mois	= 2CHIFFRES  ; 01-12
date-mjour	= 2CHIFFRES  ; 01-28, 01-29, 01-30, 01-31 selon le mois de l'année
heure-heure	= 2CHIFFRES  ; 00-23
heure-minute	= 2CHIFFRES  ; 00-59
heure-seconde	= 2CHIFFRES  ; 00-58, 00-59, 00-60 selon les règles de saut de secondes
heure-secfrac	= "." 1*CHIFFRE
heure-numdécal	= ("+" / "-") heure-heure ":" heure-minute
heure-décal	= "Z" / heure-numdécal

heure-partielle	= heure-heure ":" heure-minute ":" heure-seconde  [heure-secfrac]
date-pleine	= date-année "-" date-mois "-" date-mjour
heure-pleine	= heure-partielle heure-décal

date-heure	= date-pleine "T" heure-pleine

NOTE : Selon [ABNF] et ISO8601, les caractères "T" et "Z" dans cette syntaxe peuvent aussi être en minuscules, respectivement "t" ou "z".

Ce format de date/heure peut être utilisé dans certains environnements ou contextes qui font une distinction entre les lettres majuscules 'A'-'Z' et les lettres minuscules 'a'-'z' (par exemple, XML). Les spécifications qui utilisent ce format dans de tels environnements PEUVENT apporter d'autres limitations à la syntaxe de date/heure de façon à ce que les lettres 'T' et 'Z' utilisées dans la syntaxe de date/heure soient toujours en majuscules. Les applications qui génèrent ce format DEVRAIENT utiliser les lettres majuscules.

Note : La norme ISO 8601 définit la date et l'heure séparées par "T". Les applications qui utilisent cette syntaxe peuvent choisir, au nom de la lisibilité, de spécifier une date-pleine et une heure-pleine séparées par un caractère espace (par exemple).

5.7	Restrictions

L'élément de grammaire date-mjour représente le nombre de jours au sein du mois en cours. La valeur maximum varie selon le mois et l'année comme suit :

Numéro du mois	Mois de l'année	Valeur maximale du nombre de jours du mois	
01	janvier	31	
02	février, normal	28	
02	février, année bissextile	29	
03	mars	31	
04	avril	30	
05	mai	31	
06	juin	30	
07	juillet	31	
08	août	31	
09	septembre	30	
10	octobre	31	
11	novembre	30	
12	décembre	31	

L'Appendice C contient un échantillon de code C pour déterminer si une année est une année bissextile

L'élément de grammaire heure-seconde peut avoir la valeur "60" à la fin de mois dans lesquels survient un saut de seconde – à savoir : juin (XXXX-06-30T23:59:60Z) ou décembre (XXXX-12-31T23:59:60Z) ; voir à l'appendice D un tableau de secondes sautées. Il est aussi possible qu'une seconde sautée soit soustraite, auquel cas la valeur maximum d'une heure-seconde est "58". À tous les autres moments la valeur maximum d'une heure-seconde est "59". De plus, dans les zones horaires autres que "Z", le point de seconde sautée se déplace avec le décalage de zone (de sorte qu'il arrive au même instant tout autour du globe).

Les secondes sautées ne peuvent pas être prédites longtemps à l'avance. Le service international de la rotation de la Terre (IERS, International Earth Rotation Service) publie des bulletins [IERS] qui annoncent les secondes sautées quelques semaines à l'avance. Les applications ne devraient pas générer d'horodatages impliquant des sauts de seconde insérés avant que le saut de seconde ne soit annoncé.

Bien que la norme ISO 8601 permette que l'heure soit "24", le présent profil de ISO 8601 ne permet que des valeurs entre "00" et "23" pour l'heure afin de réduire la confusion.

5.8	Exemples

Voici quelques exemples de format date/heure de l'Internet.

1985-04-12T23:20:50.52Z

Cela représente 20 minutes et 50,52 secondes après la 23ème heure du 12 avril 1985 en UTC.

1996-12-19T16:39:57-08:00

Cela représente 39 minutes et 57 secondes après la 16ème heure du 19 décembre 1996 avec un décalage de - 08:00 sur l'UTC (Heure du Pacifique). Noter que ceci est équivalent à 1996-12-20T00:39:57Z en UTC.

1990-12-31T23:59:60Z

Cela représente le saut de seconde inséré à la fin de 1990.

1990-12-31T15:59:60-08:00

Cela représente la même seconde sautée dans l'heure standard du Pacifique , 8 heures après l'UTC.

1937-01-01T12:00:27.87+00:20

Cela représente le même instant que midi du 1er janvier 1937, heure des Pays-Bas. L'heure standard légale aux Pays-Bas était exactement 19 minutes et 32,13 secondes en avance de l'UTC depuis le 1909-05-01 jusqu'au 1937-06-30. Cette zone horaire ne peut pas être représentée exactement en utilisant le format HH:MM, et cet horodatage utilise le décalage UTC le plus proche représentable.

6.	Références

[ZELLER]	Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol. 9, novembre 1886.

[IMAIL]	D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", RFC 822, STD 11, août 1982.

[RFC2822]	P. Resnick, "Format des messages de l'Internet", avril 2001.

[ABNF]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 2234, novembre 1997.

[ISO8601]	"Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, juin 1988.

[ISO8601:2000]	"Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:2000, International Organization for Standardization, décembre 2000.

[HOST-REQ]	R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", RFC 1123, STD  3, octobre  1989.

[IERS]	International Earth Rotation Service Bulletins, <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.

[NTP]	D. Mills, "Protocole de l'heure du réseau, version 3, spécification, mise en œuvre et analyse", RFC 1305, STD 12, mars  1992.

[ITU-R-TF]	International Telecommunication Union Recommendations for Time Signals and Frequency Standards Emissions. <http://www.itu.ch/publications/itu-r/iturtf.htm>

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

7.	Considérations pour la sécurité

Dans la mesure où la zone horaire locale d'un site peut être utile pour déterminer l'heure à laquelle des systèmes ont moins de chances d'être surveillés et pourraient être plus vulnérables à une atteinte à la sécurité, certains sites peuvent souhaiter émettre les heures seulement en UTC. D'autres peuvent considérer cela comme la perte d'une fonctionnalité utile au nom d'une forme de paranoïa.

Appendice A	ABNF de la norme ISO 8601

Ces informations se fondent sur la version 1988 de la norme ISO 8601. Des changements ont pu intervenir dans la révision de 2000.

La norme ISO 8601 ne spécifie pas une grammaire formelle pour les formats de date et d'heure qu'elle définit. Ce qui suit est une tentative pour créer une grammaire formelle à partir de la norme ISO 8601. Ceci n'est que pour information et peut contenir des erreurs. La norme ISO 8601 reste la seule référence faisant autorité.

Noter que du fait d'ambiguïtés dans la norme ISO 8601, certaines interprétations ont dû être faites. D'abord, ISO 8601 n'est pas claire sur le point de savoir si sont permis des mélanges de format de base et de format étendu. Cette grammaire permet les mélanges. ISO 8601 n'est pas claire sur le point de savoir si une heure de 24 est permise seulement si les minutes et les secondes sont 0. Cela suppose qu'une heure de 24 est permise dans tout contexte. Les restrictions sur date-mjour du paragraphe 5.7 s'appliquent. ISO 8601 déclare que le "T" peut être omis dans certaines circonstances. Cette grammaire exige le "T" pour éviter les ambiguïtés. ISO 8601 exige aussi (au paragraphe 5.3.1.3) qu'une fraction décimale soit précédée d'un "0" si elle est inférieure à l'unité. L'annexe B.2 de ISO 8601 donne des exemples où les fractions décimales ne sont pas précédées par un "0". Cette grammaire suppose que le paragraphe 5.3.1.3 est correct et que l'Annexe B.2 est erronée.

date-siècle	= 2CHIFFRES	; 00-99
date-décade	=  CHIFFRE	; 0-9
date-sous-décade	=  CHIFFRE	; 0-9
date-année	= date-décade date-sous-décade
date-année-pleine	= date-siècle date-année
date-mois	= 2CHIFFRES	; 01-12
date-jour-de-la-semaine	=  CHIFFRE	; 1-7  ; 1 est lundi, 7 est dimanche
date-mjour	= 2CHIFFRES	; 01-28, 01-29, 01-30, 01-31 selon le mois de l'année
date-jour-de-l'année	= 3CHIFFRES	; 001-365, 001-366 selon l'année
date-semaine	= 2CHIFFRES	; 01-52, 01-53 selon l'année

datepart-année-pleine	= [date-siècle] date-année ["-"]
datepart-ptannée	= "-" [date-sous-décade ["-"]]
datepart-semaine-année	= datepart-ptannée / datepart-année-pleine

dateopt-siécle	= "-" / date-siècle
dateopt-année-pleine	= "-" / datepart-année-pleine
dateopt-année	= "-" / (date-année ["-"])
dateopt-mois	= "-" / (date-mois ["-"])
dateopt-semaine	= "-" / (date-semaine ["-"])
datespec-pleine	= datepart-année-pleine date-mois ["-"] date-mjour
datespec-année	= date-siècle / dateopt-siècle date-année
datespec-mois	 = "-" dateopt-année date-mois [["-"] date-mjour]
datespec-mjour	= "--" dateopt-mois date-mjour
datespec-semaine	= datepart-semaine-année "W" (date-semaine / dateopt-semaine date-jour-de-la-semaine )
datespec-jour-de-la-semaine	= "---" date-jour-de-la-semaine
datespec-jour-de-l'année	= dateopt-année-pleine date-jour-de-l'année

date	= datespec-pleine / datespec-année / datespec-mois /
datespec-jour-du-mois / datespec-semaine / datespec-jour-de-la semaine / datespec-jour-de-l'année

Heure :

heure-heure	= 2CHIFFRES	; 00-24
heure-minute	= 2CHIFFRES	; 00-59
heure-seconde	 = 2CHIFFRES	; 00-58, 00-59, 00-60 selon les règles de saut de secondes
heure-fraction	= ("," / ".") 1*CHIFFRE
heure-numdécal	 = ("+" / "-") heure-heure [[":"] heure-minute]
heure-zone	= "Z" / heure-numdécal

heureopt-heure	= "-" / (heure-heure [":"])
heureopt-minute	= "-" / (heure-minute [":"])

heurespec-heure	 = heure-heure [[":"] heure-minute [[":"] heure-seconde]]
theurespec-minute	= heureopt-heure heure-minute [[":"] heure-seconde]
heurespec-seconde	= "-" heureopt-minute heure-seconde
heurespec-base	= heurespec-heure / heurespec-minute / heurespec-seconde

heure	 = heurespec-base [heure-fraction] [heure-zone]

iso-date-heure	= date "T" heure

Durées :
dur-seconde	= 1*CHIFFRE "S"
dur-minute	= 1*CHIFFRE "M" [dur-second]
dur-heure	= 1*CHIFFRE "H" [dur-minute]
dur-temps	= "T" (dur-heure / dur-minute / dur-seconde)
dur-jour	= 1*CHIFFRE "D"
dur-semaine	= 1*CHIFFRE "W"
dur-mois	= 1*CHIFFRE "M" [dur-day]
dur-année	= 1*CHIFFRE "Y" [dur-mois]
dur-date	= (dur-djour / dur-mois / dur-année) [dur-heure]

durée	= "P" (dur-date / dur-heure / dur-semaine)

Périodes :
période-explicite	= iso-date-heure "/" iso-date-heure
période-début	= iso-date-heure "/" durée
période-fin	= durée "/" iso-date-heure

période	= période-explicite / période-début / période-fin

Appendice B.	Jour de la semaine

Ce qui suit est un échantillon de sous-programme en langage C vaguement fondé sur la congruence de Zeller [Zeller] qui peut être utilisé pour obtenir le jour de la semaine pour les dates sur ou après 0000-03-01 :

char *day_of_week(int day, int month, int year)
{
   int cent;
   char *dayofweek[] = {
      "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"
  };

      /* ajuste les mois pour que février soit le dernier */
      month -= 2;
      if (month < 1) {
         month += 12;
         --year;
      }
      /* partagé par siècles */
      cent = year / 100;
      year %= 100;
      return (dayofweek[((26 * month - 2) / 10 + day + year + year / 4 + cent / 4 + 5 * cent) % 7]);
   }

Appendice C	Années bisextiles

Voici un échantillon de sous-programme en langage C pour calculer si une année est bissextile :

/* Ceci retourne une valeur différente de zéro si l'année est bissextile. On doit utiliser une année à  4 chiffres. */
   int leap_year(int year)
   {
       return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
   }

Appendice D 	Secondes sautées

Des informations sur les secondes sautées se trouvent à : <http://tycho.usno.navy.mil/leapsec.html>. En particulier, on note que :

La décision d'introduire une seconde sautée dans l'UTC est de la responsabilité du Service International de la Rotation de la Terre (IERS). Conformément à la Recommandation du CCIR, la préférence est données à des opportunités à la fin de décembre et de juin, et ensuite à celles qui sont à la fin de mars et de septembre.

Lorsque c'est nécessaire, l'insertion d'une seconde sautée survient comme une seconde supplémentaire à la fin d'un jour en UTC, représenté par un horodatage de forme AAAA-MM-JJT23:59:60Z. Une seconde sautée survient simultanément dans toutes les zones horaires, de sorte que les relations entre les zones horaires ne sont pas affectées. Voir au paragraphe 5.8 des exemples de secondes sautées.

Le tableau suivant est un extrait du tableau conservé par l'Observatoire Navel des États-Unis. Les données source sont situées à : <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>

Ce tableau montre la date de la seconde sautée, et la différence entre l'heure standard TAI (qui n'est pas ajustée avec les secondes sautées) et l'UTC après cette seconde sautée.

Date UTC TAI 	UTC près la seconde sautée	
1972-06-30	11	
1972-12-31	12	
1973-12-31	13	
1974-12-31	14	
1975-12-31	15	
1976-12-31	16	
1977-12-31	17	
1978-12-31	18	
1979-12-31	19	
1981-06-30	20	
1982-06-30	21	
1983-06-30	22	
1985-06-30	23	
1987-12-31	24	
1989-12-31	25	
1990-12-31	26	
1992-06-30	27	
1993-06-30	28	
1994-06-30	29	
1995-12-31	30	
1997-06-30	31	
1998-12-31	32	

Remerciements

Les personnes suivantes ont fourni des avis utiles pour une réalisation précédente du présent document : Ned Freed, Neal McBurnett, David Keegel, Markus Kuhn, Paul Eggert et Robert Elz. Des remerciements sont également dus aux participants à la liste de diffusion du groupe de travail Calendaring/Scheduling de l'IETF, et à ceux de la liste de diffusion du groupe fuseaux horaires.

Les réviseurs suivants ont heureusement contribué par des suggestions utiles à la présente révision : Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn. Paul Eggert a fourni de nombreuses observations pertinentes concernant les subtilités des sauts de secondes et des décalages de fuseau horaire. Les personnes suivantes ont fait remarquer des corrections et proposé des améliorations à des projets antérieurs : Dr John Stockton, Jutta Degener, Joe Abley, et Dan Wing.

Adresse des auteurs

Chris Newman	Graham Klyne (éditeur de cette révision)	
Sun Microsystems	Clearswift Corporation	
1050 Lakes Drive, Suite 250	1310 Waterside	
West Covina, CA 91790 	Arlington Business Park	
USA	Theale, Reading  RG7 4SA	
	UK	
	téléphone : +44 11 8903 8903	
	Fax :   +44 11 8903 9000	
mél : chris.newman@sun.com 	mél : GK@ACM.ORG 	

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.