Vivement 2038 !

Vous avez sans doute tous entendu parler du bug de l’an 2000, qui n’en était pas vraiment un. L’apparition de 3 zéros sur les calendriers faisait redouter aux informaticiens un problème qui n’en était pas vraiment un. Finalement, la vraie année merdique, c’est 2038. Je m’en suis rendu compte aujourd’hui même à mes dépends.

Au départ, une simple boucle sur un tableau de date. Mon but était de trouver la date minimale. Par simplicité, même si c’est moche, j’avais décidé d’initialiser la boucle à une date fort lointaine : 2500 ! Avec ça, j’étais tranquille, pensais-je.

$minDate = new \Datetime;
$minDate->setDate(2500, 01, 01); // "avec ça, je suis tranquille !"

foreach($dates as $date){
    // celui qui me dit que j'aurais pu utiliser diff(), je le blâme
    if ($date->getTimestamp() < $minDate->getTimestamp()){
        $minDate = $date;
    }
}
return $minDate;

Quelle ne fut pas ma surprise de constater que cette méthode me renvoyait toujours NULL ! Après quelques recherche j’ai essayé de diminuer ma date initiale, jusqu’à 2022, et ça marchait. Une rapide recherche du « max time() » sur Google m’a ramené la page du bug de l’an 2038.

Le concept est simple : un temps POSIX (timestamp) est représenté par un nombre immense, à savoir le nombre de secondes écoulées depuis le 1er Janvier 1970 à minuit. Finalement, en 2038, le 19 janvier à 3h 14m et 7s pour être tout à fait exact, ce nombre de secondes dépassera le fameux 2^32 – 1 (codage sur 32 bits) et on aura donc un magnifique plantage de tous les algorithmes basés sur ce temps POSIX. Le problème arrivera même avant, vu que certains algorithme vont certainement chercher une date dans le future, par exemple « date du jour + 2 ans » ; ceux-ci planteront dès 2036.

Heureusement les développeurs ont déjà anticipé, et les timestamps sont déjà en train de basculer sur un codage 64 bits, ce qui devrait alors nous autoriser quelques centaines… de milliards d’années supplémentaires. Ouf 🙂