J'utilise un système Ubuntu 64 bits.
Je travaille actuellement sur un projet intégrant MariaDB. Je prévois d’introduire la technique d’horodatage dans le projet afin que les personnes reçoivent l’heure exacte pour un fuseau horaire différent.
J'ai entendu et lu des articles sur le problème de l'année 2038 pour l'horodatage. De nombreux articles suggèrent que nous utilisons un système 64 bits pour gagner un peu plus de temps.
À combien de temps ce "bit" fait-il référence? Est-ce assez long pour que nous puissions gérer des applications Web jusqu'au bout? Si ce n’est pas le cas, est-ce que c’est comme une prolongation de deux ans seulement, alors quand l’année 2040 arrivera, aurons-nous des applications qui ne fonctionneront pas correctement?
Eh bien, s’il est possible d’acheter littéralement un "bit", c’est-à-dire un transfert d’un nombre entier signé 32 bits à un nombre entier non signé 32 bits, les choses continuent de fonctionner en 2106.
Transférer en 64 bits est "un peu mieux". Vous obtenez des centaines de milliards d'années de résolution.
Et Ubuntu fait ceci:
$ uname -p
x86_64
$ date --date=9090-01-01 +%s
224685532800
Cependant, c'est le niveau de l'OS. Ce n’est pas parce que Ubuntu utilise un entier de 64 bits pour son temps que MySQL/MariaDB l’utilisera pour stocker ses horodatages. Si les dates après 2038 sont importantes pour vous maintenant, commencez le test immédiatement.
En fait, je peux vous faire gagner du temps. C'est encore cassé. Ce bogue a été rapporté il y a plus de dix ans mais son test principal échoue toujours avec un 64bit int.
mysql> select from_unixtime(2548990800);
+---------------------------+
| from_unixtime(2548990800) |
+---------------------------+
| NULL |
+---------------------------+
1 row in set (0.00 sec)
Ce n'est même pas de stockage. C'est légèrement pathétique.
(Et oui, cela a été exécuté sur MariaDB, version 10.1)
Ne le stockez pas comme un entier du tout. Stockez-le en tant que ISO 8601 chaîne de date formatée. C'est le format standard utilisé sur Internet.
9999-12-31T23:59:59+00:00