Il y a un tel problème - en 2038, le
nombre de secondes depuis le début de l'ère Unix Time dépassera la valeur de int signé et disparaîtra. C'est comme le problème de 2000, mais beaucoup plus compliqué, car pour cela, vous devez changer les types de données.
Donc ... dans MySQL,
depuis quatorze ans et demi, une requête a été suspendue pour corriger les fonctions UNIX_TIMESTAMP et FROM_UNIXTIME, qui ne peuvent pas traiter les dates après le 19 janvier 2038. Ce sont des fonctions pour convertir des dates en Unixtime et vice versa.
La vérification est assez simple: essayez cette requête.
select unix_timestamp('2038-01-20');
En 2017, une personne gentille a essayé de le réparer, mais le patch n'a jamais été accepté. Problèmes avec les fuseaux horaires et la prise en charge des systèmes 32 bits.
Passer à MariaDB n'est pas non plus une option: là, ce bug est
déjà fermé car trop compliqué.L'apocalypse arrive et nous ne pouvons que prier ... pour ces développeurs.
PS Maintenant, sérieusement:
il y a un avertissement dans la documentation que le type TIMESTAMP se transforme en citrouille après 2038. Mais personne n'a mis en garde contre les fonctions de conversion de temps. Il s'avère que tous les Unix et de nombreux langages de programmation sont déjà passés à des horodatages 64 bits, et seules les fonctions MySQL cesseront de comprendre Unixtime sans raison apparente.