PHP & mySQL: Année 2038 Bogue: Qu'est-ce que c'est? Comment le résoudre?

Je pensais utiliser TIMESTAMP pour stocker la date et l'heure, mais j'ai lu qu'il y avait une limitation de l'année 2038 dessus. Au lieu de poser ma question en gros, j'ai préféré la diviser en petites parties pour qu'elle soit également facile à comprendre pour les utilisateurs novices. Donc ma (mes) question (s):

1. Quel est exactement le problème de l'an 2038?
2. Pourquoi cela se produit-il et que se passe-t-il quand cela se produit?
3. Comment pouvons-nous le résoudre?
4. Existe-t-il des alternatives possibles à son utilisation, qui ne posent pas un problème similaire?
5. Que pouvons-nous faire aux applications existantes qui utilisent TIMESTAMP, pour éviter le soi-disant problème, quand il se produit vraiment?

Merci d'avance.

J'ai marqué ceci comme un wiki communautaire, alors n'hésitez pas à le modifier à votre guise.

Quel est exactement le problème de l'an 2038?

"Le problème de l'année 2038 (également connu sous le nom de bogue Unix Millennium, l'an 2000 par analogie avec le problème de l'an 2000) peut entraîner l'échec de certains logiciels avant ou pendant l'année 2038. Le problème affecte tous les logiciels et systèmes qui stockent l'heure système sous la forme d'un 32 -bit integer et interpréter ce nombre comme le nombre de secondes depuis 00:00:00 UTC le 1er janvier 1970. "

Pourquoi cela se produit-il et que se passe-t-il quand cela se produit?

Les heures au-delà de 03:14:07 UTC le mardi 19 janvier 2038 «s'enrouleront» et seront stockées en interne sous la forme d'un nombre négatif, que ces systèmes interpréteront comme une heure du 13 décembre 1901 plutôt qu'en 2038. Cela est dû à le fait que le nombre de secondes depuis l'époque UNIX (1er janvier 1970 00:00:00 GMT) aura dépassé la valeur maximale d'un ordinateur pour un entier signé de 32 bits.

Comment pouvons-nous le résoudre?

• Utilisez des types de données longs (64 bits suffisent)
• Pour MySQL (ou MariaDB), si vous n'avez pas besoin des informations de temps, envisagez d'utiliser le DATEtype de colonne. Si vous avez besoin d'une précision plus élevée, utilisez DATETIMEplutôt que TIMESTAMP. Attention, les DATETIMEcolonnes ne stockent pas d'informations sur le fuseau horaire, votre application devra donc savoir quel fuseau horaire a été utilisé.
• Autres solutions possibles décrites sur Wikipedia
• Attendez que les développeurs MySQL corrigent ce bogue signalé il y a plus de dix ans.

Existe-t-il des alternatives possibles à son utilisation, qui ne posent pas un problème similaire?

Essayez dans la mesure du possible d'utiliser de grands types pour stocker des dates dans des bases de données: 64 bits suffit - un type long long en GNU C et POSIX / SuS, ou sprintf('%u'...)en PHP ou l'extension BCmath.

Quels sont les cas d'utilisation potentiellement cassants même si nous ne sommes pas encore en 2038?

Ainsi, un DATETIME MySQL a une plage de 1000 à 9 999, mais TIMESTAMP n'a qu'une plage de 1970 à 2038. Si votre système stocke les dates de naissance, les dates futures futures (par exemple, les hypothèques à 30 ans) ou similaire, vous allez déjà rencontrer ce bogue. Encore une fois, n'utilisez pas TIMESTAMP si cela pose un problème.

Que pouvons-nous faire aux applications existantes qui utilisent TIMESTAMP, pour éviter le soi-disant problème, quand il se produit vraiment?

Peu d'applications PHP seront encore disponibles en 2038, bien qu'il soit difficile de prévoir que le Web n'est pas encore une plate-forme héritée.

Voici un processus pour modifier une colonne de table de base de données pour convertir TIMESTAMPà DATETIME. Cela commence par la création d'une colonne temporaire:

# rename the old TIMESTAMP field
ALTER TABLE `myTable` CHANGE `myTimestamp` `temp_myTimestamp` int(11) NOT NULL;

# create a new DATETIME column of the same name as your old column
ALTER TABLE `myTable` ADD `myTimestamp` DATETIME NOT NULL;

# update all rows by populating your new DATETIME field
UPDATE `myTable` SET `myTimestamp` = FROM_UNIXTIME(temp_myTimestamp);

# remove the temporary column
ALTER TABLE `myTable` DROP `temp_myTimestamp`

Ressources

• Problème de l'année 2038 (Wikipedia)
• Internet prendra fin dans 30 ans

Lorsque vous utilisez des horodatages UNIX pour stocker des dates, vous utilisez en fait un nombre entier de 32 bits, qui tient compte du nombre de secondes depuis le 01/01/1970; voir l' heure Unix

Ce nombre de 32 bits débordera en 2038. C'est le problème de 2038.

Pour résoudre ce problème, vous ne devez pas utiliser un horodatage UNIX 32 bits pour stocker vos dates - ce qui signifie que lorsque vous utilisez MySQL, vous ne devez pas utiliser TIMESTAMP, mais DATETIME(voir 10.3.1. Les types DATETIME, DATE et TIMESTAMP ):

Le DATETIMEtype est utilisé lorsque vous avez besoin de valeurs contenant à la fois des informations de date et d'heure. La plage prise en charge est '1000-01-01 00:00:00'de '9999-12-31 23:59:59'.

Le TIMESTAMPtype de données a une plage de '1970-01-01 00:00:01'UTC à '2038-01-19 03:14:07'UTC.

La meilleure chose (probablement) que vous puissiez faire à votre application pour éviter / résoudre ce problème est de ne pas utiliser TIMESTAMP, mais DATETIMEpour les colonnes qui doivent contenir des dates qui ne sont pas comprises entre 1970 et 2038.

Une petite note, cependant: il y a une très grande probabilité (statistiquement parlant) que votre candidature ait été réécrite plusieurs fois avant 2038 ^^ Alors peut-être, si vous n'avez pas à vous occuper de dates dans le futur , vous n'aurez pas à vous occuper de ce problème avec la version actuelle de votre application ...

Une recherche rapide sur Google fera l'affaire: problème de l'année 2038

1. Le problème de l'année 2038 (également connu sous le nom de bogue Unix Millennium, Y2K38 par analogie avec le problème de l'an 2000) peut provoquer l'échec de certains logiciels avant ou pendant l'année 2038.
2. Le problème affecte tous les logiciels et systèmes qui stockent l'heure système sous la forme d'un entier 32 bits signé et interprètent ce nombre comme le nombre de secondes depuis 00:00:00 UTC le 1er janvier 1970. La dernière heure qui peut être représentée de cette façon est 03:14:07 UTC le mardi 19 janvier 2038. Les heures au-delà de ce moment "s'enrouleront" et seront stockées en interne sous la forme d'un nombre négatif, que ces systèmes interpréteront comme une date en 1901 plutôt qu'en 2038
3. Il n'y a pas de solution facile à ce problème pour les combinaisons CPU / OS existantes, les systèmes de fichiers existants ou les formats de données binaires existants

http://en.wikipedia.org/wiki/Year_2038_problem contient la plupart des détails

En résumé:

1) + 2) Le problème est que de nombreux systèmes stockent les informations de date sous la forme d'un entier signé 32 bits égal au nombre de secondes depuis le 1/1/1970. La dernière date qui peut être stockée de cette manière est 03:14:07 UTC le mardi 19 janvier 2038. Lorsque cela se produit, l'int "s'enroule" et est stocké comme un nombre négatif qui sera interprété comme une date en 1901. Ce qui se passera alors exactement varie d'un système à l'autre, mais il suffit de dire que ce ne sera probablement pas bon pour aucun d'entre eux!

Pour les systèmes qui ne stockent que des dates dans le passé, alors je suppose que vous n'avez pas à vous inquiéter pendant un moment! Le principal problème est avec les systèmes qui fonctionnent avec des dates dans le futur. Si votre système doit fonctionner avec des dates de 28 ans dans le futur, vous devriez commencer à vous inquiéter maintenant!

3) Utilisez l'un des formats de date alternatifs disponibles ou passez à un système 64 bits et utilisez des entiers 64 bits. Ou pour les bases de données, utilisez un autre format d'horodatage (par exemple pour MySQL, utilisez DATETIME)

4) Voir 3!

5) Voir 4 !!! ;)

Bros, si vous avez besoin d'utiliser PHP pour afficher les horodatages, c'est la MEILLEURE solution PHP sans changer du format UNIX_TIMESTAMP.

Utilisez une fonction custom_date (). À l'intérieur, utilisez le DateTime. Voici la solution DateTime .

Tant que vous avez UNSIGNED BIGINT (8) comme horodatage dans la base de données. Tant que vous avez PHP 5.2.0 ++

Comme je ne voulais rien mettre à jour, j'ai demandé à mon backend (MSSQL) de faire ce travail au lieu de PHP!

$qry = "select DATEADD(month, 1, :date) next_date ";
$rs_tmp = $pdo->prepare($qry);
$rs_tmp->bindValue(":date", '2038/01/15');
$rs_tmp->execute();
$row_tmp = $rs_tmp->fetch(PDO::FETCH_ASSOC);

echo $row_tmp['next_date'];

Ce n'est peut-être pas un moyen efficace, mais cela fonctionne.