La gigaseconde Unix et le 11 Septembre

Comme vous le savez, le temps Unix est d=E9comp=E9 en secondes (y compris
les
secondes intercalaires) depuis le 1er Janvier 1970 temps universel.

Du 03 mars 1973 au 09 septembre 2001, cette quantit=E9 se repr=E9sente sur
9
chiffres d=E9cimaux exactement. Le basculement de 9 =E0 10 chiffres a eu
lieu
le dimanche 9 septembre 2001 =E0 01:46:40 UTC.

Cet instant est parfois appel=E9 "billenium", contraction de billion
(10^9)
et millenium. Un certain nombre de syst=E8mes ont connu des bugs =E0 cet
instant. On peut facilement imaginer une colonne SQL limit=E9e =E0 9
chiffres d=E9cimaux, ou bien un timestamp formatt=E9 sur 9 chiffres et
mal pars=E9, ou un buffer overflow (faut le faire, le buffer radin =E0
9 octets).

On peut imaginer que des syst=E8mes financiers, bancaires ou de s=E9curit=
=E9
ont connu un dysfonctionnement =E0 cette date. C'=E9tait dimanche. Si
le probl=E8me a =E9t=E9 constat=E9 lundi, le temps de trouver le bon ing=E9=
nieur
etc. et il est facilement mardi.

Mardi 11 septembre 2001, =E0 08:46:40 heure d'=E9t=E9 de New York (EDT),
un avion impacte la tour nord du World Trade Center.

Cet instant correspond au billenium, plus 59 heures.

Quand je dis 59 heures, c'est 59 heures, 00 minutes, et 00 secondes.
Vous remarquerez par ailleurs que 08:46:40 n'est pas une heure
sp=E9ciale.
M=EAme si on n'est pas tr=E8s loin du quart d'heure, c'est intriguant.

Bref, on sait qu'il y a eu des op=E9rations financi=E8res bizarres juste
avant le 11 septembre. Ces op=E9rations =E9taient-elles l'exploitation
d'un "billenium bug" affectant des syst=E8mes financiers (ou de
surveillance
des march=E9s financiers?)

On peut aussi imaginer que des programmeurs v=E9reux aient sciemment
ins=E9r=E9 des "billenium bugs" pour ensuite vendre l'information =E0 leurs
copains traders.

=C0 chacun de se former une opinion.

Mais la date du 11 septembre est aussi particuli=E8re par rapport au
billenium bug.

Un ordinateur qui se serait embrouill=E9 les p=E9dales =E0 cause de ce
billenium bug,
s'embrouillerait le samedi 9 septembre =E0 21:46:40. Il se croirait
alors
mercredi 31 d=E9cembre 1969. Le prochain samedi qu'il verra sera le
samedi 3
janvier 1970. En r=E9alit=E9 il sera dans la nuit du mardi 11 au mercredi
12
septembre 2001, =E0 00:33:20.

Maintenant si vous avez un syst=E8me ou vous lancez un job et que celui-
ci
calcule le temps de sa prochaine invocation qu'il programme avec cron,
et qu'il utilise le jour et l'heure, le sc=E9nario suivant peut se
d=E9rouler.

Disons que notre job s'ex=E9cute habituellement tous les quarts d'heure.
Il est samedi 09 septembre. =C0 21h45 la t=E2che s'ex=E9cute, et se
reprogramme
pour samedi =E0 22h00.

Imaginons que le cron en question souffre du millenium bug (par
exemple
parce qu'en fait c'est un syst=E8me maison de programmation de t=E2ches =E0
distance, et que leur protocole pourri n'a que 9 chiffres pour le
timestamp,
ou quelque chose comme =E7a.)

Le samedi 22h00 qu'il attendra aura donc lieu en fait le mercredi 12
septembre
2001 =E0 00:46:40, que le programme verra comme le samedi 3 janvier 1970
22:00.

Entretemps, c'est-=E0-dire depuis le samedi 9 septembre, la t=E2che ne
sera pas ex=E9cut=E9e.

Donc le 11 septembre est, pour une certaine classe assez raisonnable
de
billenium bugs, le dernier jour o=F9 une t=E2che devant s'ex=E9cuter
p=E9riodiquement
aurait =E9t=E9 suspendue depuis le bug.

--
Guillaume D'Ock