]>
&header;
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.
&footer;