Skip site navigation (1) Skip section navigation (2)

Compatibilité An 2000 (bug de l'an 2000)

A mesure que les décideurs prennent conscience du problème de l'an 2000 (bug de l'an 2000), de plus en plus de sociétés réclament un avis officiel de la part de leurs fournisseurs de matériels et de logiciels sur le passage à l'an 2000 de leurs produits.

Les organisations qui utilisent des systèmes UNIX® ou très proche d'Unix tel que FreeBSD ne sont pas concernées par ce problème. FreeBSD conservera un temps correct bien après le passage de l'an 2000.

Informations générales

(Cette section est basée sur le texte de la page consacrée à la compatibilité de Linux avec l'an 2000)

Comme avec tous les systèmes Unix et très proche d'Unix, les heures et les dates dans FreeBSD sont représentées de façon interne par le nombre de secondes écoulées depuis le 1er Janvier 1970 ("l'Epoque" Unix). Actuellement, ce chiffre est stocké dans un entier 32 bits, ce qui lui permet d'être valide jusqu'en 2038. Avant cette date, nous devrions (si tout va bien) utiliser un compteur sur 64 bits (ou plus) qui devrait être valide jusqu'à la fin de l'univers.

Notez bien qu'un système d'exploitation compatible An 2000 ne pourra pas corriger les applications mal écrites qui ne sont pas compatibles An 2000.

Notez aussi que le système d'exploitation s'attends à lire la date et l'heure courante depuis l'horloge CMOS de votre ordinateur. Certains de ces périphériques ne gèrent pas correctement l'an 2000. Nous vous recommandons de tester chaque plate-forme individuellement pour vous assurer que l'horloge de votre matériel se comporte correctement lorsqu'elle passe de l'année 1999 à l'année 2000 et qu'elle interprète correctement l'année 2000 comme une année bissextile.

Ce que vous pouvez faire

FreeBSD continuera de maintenir un temps correct lors du siècle prochain. Certaines applications tierces peuvent cependant poser problème. Votre meilleure défense contre les problèmes liés à l'an 2000 est l'attaque. Ecouter les histoires clamant la disparition prochaine du monde tel que nous le connaissons n'est pas la meilleure façon de résoudre le bug de l'an 2000. Attendre la dernière minute non plus. Le projet FreeBSD recommande pour votre organisation d'appliquer les principes de l'administration système à mesure que le nouveau millénaire approche.

Avis officiel concernant FreeBSD et l'an 2000

"Après des tests et des analyses approfondis, nous pensons que FreeBSD est 100% compatible An 2000. Dans le cas improbable où quelque chose aurait été oublié, nous ferons de notre mieux pour y remédier dans les plus brefs délais."

David Greenman
Architecte principal, Projet FreeBSD

Problèmes résolus

Les problèmes suivants liés à l'an 2000 ont été identifiés et résolus dans FreeBSD.

misc/1380
Plusieurs programmes ont un "19%d" codé en dur pour l'année. Les programmes affectés inclus : yacc, ftpd, et make. [Correction : yacc v1.2 18/01/1999; ftpd v1.7 05/08/1996; make v1.4 06/10/1996; corrections incluses dans FreeBSD 2.2 et supérieur]
conf/1382
Le script sed dans /etc/rc.local qui construit la ligne identifiant l'hôte/noyau pour le message du jour suppose que l'année ne dépasse pas 1999. [Correction v1.21 24/10/1996; corrections incluses dans FreeBSD 2.2 et supérieur]
misc/3465
La commande etc/namedb/make-localhost génère le numéro de série DNS sous la forme YYMMDD. En l'an 2000, il sera généré sous la forme 1YYMMDD. [Correction v1.2 11/08/1997; corrections incluses dans FreeBSD 2.2.5 et supérieur]
gnu/4930 et gnu/8321
Les macros groff tmac ont codé en dur 19 pour la génération de certaines dates. [Correction : tmac.e v1.3 06/12/1998; doc-common v1.10 19/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
bin/9323
Dans sa forme obsolète, touch ne traite pas correctement les années données avec seulement 2 chiffres. Les années 00 à 68 sont traitées comme 1900 à 1968 au lieu de 2000 à 2068. [Correction v1.7 05/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
xntpd/parse/util/dcfd.c
Le calcul du nombre de jours dans l'année pour les années bissextiles et la conversion du temps DCF77 en secondes depuis l'Epoque étaient fausses. Ces erreurs affectaient toutes les années. [Correction v1.6 12/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
tar/getdate.y
La fonction Convert() étaient codées en dur pour les années en 2 chiffres de 70 à 99. Désormais corrigée pour permettre les années en 2 chiffres de 1970 à 2069. La fonction ne permet pas les années séculaires non bissextiles - alerte pour 2100 ! [Correction v1.4 12/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
fetch/http.c
Le protocole HTTP inclut un format de date obsolète qui utilise une année en 2 chiffres. Les versions précédentes de fetch interprèteraient de telles dates comme étant dans les années 19xx; après cette révision, le pivot décrit dans RFC 2068 est utilisé, ce qui permet aux années en 2 chiffres d'être interprétées comme appartenant toujours au siècle courant sauf si elles sont situées 50 ans ou plus dans le futur. Comme les serveurs HTTP qui utilisent ce format ne sont plus très répandus, cela ne devrait pas avoir un impact significatif. [Correction v1.24 15/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
misc/9500
Le script `edithook' dans le répertoire CVSROOT utilise un tm_year "brut" et affichera par conséquent 01/01/100 pour 2000-JAN-01. [Correction v1.2 17/01/1999; non applicable aux versions de FreeBSD]
bin/9501
Plusieurs fichiers cvs ne sont pas compatibles An 2000. Les scripts log.pl et sccs2rcs.csh ajoutent "19" à l'année ce qui provoque l'affichage de 19100 pour 2000. Le script log_accum.pl utilise à un endroit une année en 2 chiffres et suppose à un autre endroit que le tm_year est l'année dans le siècle au lieu du nombre d'années depuis 1900. [Correction : log.pl v1.2 15/01/1999; sccs2rcs.csh v1.3 15/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
bin/9502
Le numéro de registre 'yr' de groff est assigné depuis un (struct tm).tm_year et représente par conséquent le nombre d'années depuis 1900 et non pas l'année dans le siècle (voir définition dans troff/input.cc). [Correction, maintenant mis à modulo 100, troff/input.cc V1.2 03/06/1999; corrections incluses dans FreeBSD 3.3]
bin/9503
simple_httpd de PicoBSD utilise un tm_year "brut" et affichera par conséquent 01/01/100 pour 2000-JAN-01. [Correction v1.2 16/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
bin/9505
Adduser utilise un tm_year "brut" et affichera par conséquent un 100/01/01 pour 2000-JAN-01. [Correction v1.42 15/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
bin/9506
Cron utilise un tm_year "brut" et affichera par conséquent 100 pour 2000. [Correction v1.7 16/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
bin/9507
tcpslice(8) utilise un tm_year "brut" et affichera par conséquent 100y01m01d... pour 2000-JAN-01. Pour des raisons de compatibilité, utiliser une année en 2 chiffres jusqu'à l'an 2000. [Correction v1.8 20/01/1999; corrections incluses dans FreeBSD 3.1 et supérieur]
bin/14472
La commande Date ne prend pas les chiffres des milliers/centaines. [Correction v1.31 10/11/1999]
misc/14511
Chpass pose problème lorsqu'on utilise 00 comme année d'expiration.
bin/15852 et gnu/16045 et bin/16207
La chaîne prédéfinie \*(DT [\*(td] de Groff a un bug An 2000. [Corrigé avec la mise à jour de la version 1.15 12/01/2000]
bin/15872
at(1) pose problème avec des définitions de temps correctes si tm_year vaut 100, signale un `garbled time' (temps tronqué).
misc/16238
L'installation de KerberosIV ne fonctionne pas correctement à cause d'une date d'expiration fixée au 31/12/99 codée en dur dans la source Kerberos du 'ticket granter'. [Correction v1.24 19/09/1999]

Plus d'informations

Si vous avez des questions supplémentaires à propos de la compatibilité An 2000 de FreeBSD ou si vous avez découvert une application fonctionnant sous FreeBSD qui n'est pas compatible An 2000, veuillez contacter le projet à l'adresse freebsd-bugs@FreeBSD.org.