Ne serait-ce pas le moment d’un thread de vulgarisation sur comment un ordinateur voit une date ? Mais si ! Comme d’habitude, du trivial pour un dev ou un lecteur de Wikipédia, mais complètement obscur pour le grand public.

C’est quoi une date, déjà ? C’est un marqueur de passage du temps à partir d’un référentiel commun. Le 2 mars 2026, c’est le 2e jour du 3e mois de la 2026e année après une date fixée de manière arbitraire. La naissance présupposée de Jésus. Sauf que non. Et sauf qu’on s’en fout.

On s’en fout parce que si tout le monde s’accorde sur ce marqueur arbitraire, ça pourrait être la date de l’invention du dosimètre, ça ne changerait rien. Une fois qu’on a le point de référence on peut convertir n’importe quel calendrier.

En informatique on nomme ce point de référence un epoch. Pour le mot époque en anglais, oui. Donc une date, c’est du temps passé après un epoch. Ça reporte le problème : comment on note ce temps ?

Les humains aiment bien les unités compliquées. Notre calendrier n’est pas simple, mais parce qu’on a un petit cerveau ridicule : on regroupe nos unités de temps par gros paquets qu’on arrive À PEU PRÈS à concevoir. C’est un système paradoxalement compliqué mais plus compréhensible. On a des secondes qu’on groupe en minutes puis en heures, en jours, en mois, en années. Ou qu’on divise en millisecondes, ou nano, ou… si besoin.

Les ordinateurs, ça aime les trucs simples et ça n’a pas besoin de trucs compréhensibles par un cerveau biologique. Du coup, un ordinateur va prendre la plus petite unité de temps qu’il sait gérer, et il va stocker combien de fois cette unité de temps s’est écoulée depuis un epoch. Comme cette unité dépend de l’ordinateur, on ne peut pas la coller à une unité humaine « pour sûr » : on parle de tick.

Et voilà. C’est tout con. Et comme quand je parlais d’octet, la merde arrive maintenant. Si je dis qu’on est 354 759 960 ticks après l’epoch, ça nous fait une belle jambe : il vaut quelle unité de temps absolue, ton tick ? Et c’est quoi ton epoch ?

Et c’est là qu’arrivent nos standards. Au pluriel, oui. Parce que sinon ça serait simple et beau et merveilleux. (Spoiler : il y en a un qui a presque gagné, donc au quotidien c’est pas vraiment un problème.)

Déjà le tick : on a eu le quart de seconde et le huitième de seconde. Et même le seizième. Mais de nos jours, c’est en général la seconde qui est utilisée, ou la milliseconde quand c’est pertinent. Je ne parlerai pas des cas restants d’utilisation d’autres ticks, devenus très rares.

Mais les epochs ? Ahah, les epochs. Vous travaillez sous Excel et vous rajoutez une date ? L’ordinateur stocke le nombre de secondes passées depuis le 0 janvier 1900. Oui oui, vous avez bien lu : ZÉRO janvier. Et non, ce n’est pas le 31 décembre 1899.

Parce qu’en raison d’un bug depuis les années 80 dans Lotus 1-2-3, LE tableur de l’époque, 1900 est considéré bissextile (alors que non). Du coup il y a un jour de trop dans le décompte. Excel voulant être compatible avec les fichiers sauvés par 1-2-3, il a conservé le bug volontairement. Et comme Excel en 2026 se targue d’avoir l’obligation de pouvoir ouvrir un fichier de versions précédentes, la chaîne des versions fait que c’est toujours le cas maintenant. Le 0 janvier 1900.

Google Sheets veut être compatible mais ils ont réparé le bug de l’an 1900, donc eux ont pour epoch le… 30 décembre 1899. Ce qui d’un côté semble encore plus débile que le 0 janvier.

Vous pourriez penser que Windows fait comme Excel. Après tout il est arrivé après et provient de la même compagnie. Ahah, bande d’innocents. Votre ordinateur sous Windows compte le nombre de secondes passées depuis le… 1er janvier 1601. En vrai ça a PRESQUE un sens, le calendrier grégorien ayant des cycles de 400 ans utiles pour les années bissextiles : l’année 1601 est le début du cycle dans lequel on était quand on a codé Windows. Depuis, on est dans un nouveau cycle, démarré en 2001.

Bon, bah si vous avez un Mac, c’est donc le 1er janvier 2001 qui est l’epoch depuis macOS X. C’est une particularité d’Apple comparé à Microsoft : quand ces derniers ont la rétrocompatibilité en valeur cardinale, Apple peut tout changer dans des versions ultérieures en s’en fichant.

Puisqu’on parle de système d’exploitation, reste Linux dans les grands noms. Il hérite son epoch de son père UNIX, le 1er janvier 1970. Qui est le fameux « presque standard » dont je parlais en intro. Ici, pas d’explication bullshit : la date a été choisie au hasard. Enfin, pas vraiment : c’est un truc choisi au pif mais pour gérer une contrainte dont on va reparler.

Les anciennes versions de macOS, 1er janvier 1904. Le GPS, 6 janvier 1980. Oui, le 6. Parce que le GPS aime les semaines entières et c’est le premier dimanche de 1980. Les bases de données, soit le 01/01/1970, soit le 01/01/2000. Et enfin les systèmes de fichiers pour enregistrer vos données sur les disques durs, soit comme les OS du dessus, soit le 1er janvier 1980 comme le DOS.

Bref c’est le bordel. Quand on ne précise pas, on ose espérer qu’on parle de l’epoch UNIX, en 1970. Et que ce soit des secondes et pas des milli ou nanosecondes.

Et donc, de là, reparlons du bug de l’an 2000. Les dates affichées par les ordinateurs avaient 2 chiffres pour l’année. Du coup, arrivé au 1er janvier 2000, l’ordinateur affiche 01/01/00 : retour en 1900. Les systèmes stockant l’année pouvaient faire des trucs absolument pas prévus.

La peur était légitime, le problème grave… mais je viens de passer un thread entier à expliquer que les ordinateurs ne sauvaient pas la date comme ça. Le 01/01/1900 à 18h30, en epoch UNIX, c’est -2 208 922 200 (2 millions et des brouettes de secondes avant 1970). Le 01/01/2090 à 18h30, 946 751 400.

Il y a réellement des trucs qui auraient posé problème en 2000, mais pas autant que ce qui aura été prophétisé. C’était juste soit ne pas comprendre les ordinateurs, soit faire du buzz pour vendre une arnaque. C’est pour ça que tout s’est bien passé. Mais il y a un mais.

Si vous vous rappelez mon thread sur ce qu’est un octet, vous devriez avoir une conscience floue qu’on stocke la donnée sous forme de paquets plus ou moins gros, que l’ordinateur peut traiter en une fois. Cette « largeur » de paquet, ça a été un argument marketing fort des consoles. 8 bits, 16 bits, 32 bits, Nintendo 64, Jaguar 128 bits ! Bon, bah la taille maximum de ces paquets donne la taille maximum d’un nombre en mémoire.

Stocké sur 16 bits, un nombre peut être situé entre 0 et 65 035 (2 puissance 16 valeurs). Du coup la date la plus grande qu’un ordinateur puisse conserver en 16 bits, c’est 65 035 secondes après le 01/01/1970, soit… le 01/01/1970. Mais à 18h04. Pas très pratique.

Si on garde la date sur 32 bits (2³²), ça fait 4 294 967 296 valeurs, donc la date la plus grande serait le 07/02/2106 vers 6h30. Booon. Mais. Attendez. Comment on fait pour les dates AVANT 1970 ? Bah on réserve la moitié des nombres possibles pour les nombres négatifs. Du coup notre date la plus grande n’est pas 4 milliards et quelques secondes après 1970. Non. C’est 2 147 483 647. Soit… le 19 janvier 2038 à 4h15.

Et c’est pour ça qu’on a choisi 1970 chez UNIX. Parce que ça permettait, en 32 bits, d’avoir des dates remontant dans le passé de manière raisonnable pour les comptables (date minimum au 13/12/1901) et suffisamment dans le futur pour qu’on trouve un truc entre-temps.

Sauf que ce futur, c’est demain ou presque. Et là c’est pas la même marmelade que le bug de l’an 2000. À part sur des systèmes 100 % Apple, TOUT risque de bugger complètement PARTOUT et GRAVEMENT si pas mis à jour. La solution consiste à coder la date sur 64 bits. (Ça nous permet d’avoir des dates jusqu’à la mort de l’univers, donc c’est la dernière panique de date.) Mais vu le nombre de systèmes à changer, bon courage au monde. Si on n’est pas morts avant.

Mais si on meurt avant, au moins vous aurez appris avant comment un ordinateur calcule une date. Lomig out.