Aller au contenu principal

3. Années à deux chiffres

Les exigences suivantes traitent des problèmes d'ambiguïté causés par les années à deux chiffres :

Exigences

o Les années à quatre chiffres sont obligatoires

Les protocoles Internet doivent (MUST) générer des années à quatre chiffres dans les dates.

Exemples corrects :

✅ 2002-07-15
✅ 1999-12-31

Exemples incorrects :

❌ 02-07-15
❌ 99-12-31

o Les années à deux chiffres sont dépréciées

L'utilisation d'années à deux chiffres est dépréciée (Deprecated). Si une année à deux chiffres est reçue, elle ne devrait (SHOULD) être acceptée que si une mauvaise interprétation ne causera pas d'échec de protocole ou de traitement (par exemple, si elle est utilisée uniquement à des fins de journalisation ou de traçage).

o Gestion des années à trois chiffres

Les programmes qui utilisent des années à deux chiffres peuvent représenter les années après 1999 sous forme de trois chiffres. Cela se produira si le programme soustrait simplement 1900 de l'année sans vérifier le nombre de chiffres. Les programmes qui souhaitent gérer de manière robuste les dates générées par de tels logiciels défectueux peuvent (MAY) ajouter 1900 aux années à trois chiffres.

Exemple :

Sortie du programme défectueux : 102 (représentant l'année 2002)
Analyse robuste : 102 + 1900 = 2002

o Gestion des chiffres de décennie non numériques

Les programmes qui utilisent des années à deux chiffres peuvent représenter les années après 1999 comme ":0", ":1", ... ":9", ";0", .... Cela se produira si le programme soustrait simplement 1900 de l'année et ajoute le chiffre de la décennie au caractère zéro US-ASCII. Les programmes qui souhaitent gérer de manière robuste les dates générées par de tels logiciels défectueux devraient (SHOULD) détecter les chiffres de décennie non numériques et les interpréter de manière appropriée.

Exemple :

Sortie du programme défectueux :
- '0' + 10 = ':' (représentant les années 2000, code ASCII 58)
- '0' + 11 = ';' (représentant les années 2010, code ASCII 59)

L'analyse robuste doit reconnaître ces modèles et les convertir correctement

Leçons du bogue de l'an 2000

Les problèmes liés aux années à deux chiffres démontrent amplement pourquoi toutes les dates et heures utilisées dans les protocoles Internet doivent (MUST) être entièrement qualifiées (Fully Qualified).


Recommandations d'implémentation

Lors de la génération de dates

✅ Toujours utiliser des années à quatre chiffres : 2024-12-21
❌ Ne jamais utiliser deux chiffres : 24-12-21

Lors de l'analyse de dates

# Exemple d'analyse robuste
def parse_year(year_str):
if len(year_str) == 4:
return int(year_str) # Quatre chiffres corrects
elif len(year_str) == 2:
# Déprécié, pour compatibilité ascendante uniquement
year = int(year_str)
if year < 70:
return 2000 + year
else:
return 1900 + year
elif len(year_str) == 3:
# Gérer les logiciels défectueux
return 1900 + int(year_str)
else:
raise ValueError("Format d'année invalide")

Avertissement : Bien que cette section décrive comment gérer les années à deux chiffres, cela est uniquement pour la compatibilité ascendante. Les nouvelles implémentations ne doivent absolument pas (MUST NOT) générer d'années à deux chiffres.