PHP &mySQL:År 2038 Bug:Hvad er det? Hvordan løses det?

Jeg har markeret dette som en fællesskabswiki, så du er velkommen til at redigere, når du har lyst.

Hvad er År 2038-problemet helt præcist?

"År 2038-problemet (også kendt som Unix Millennium Bug, Y2K38 i analogi med Y2K-problemet) kan forårsage, at noget computersoftware fejler før eller i år 2038. Problemet påvirker al software og systemer, der lagrer systemtid som en signeret 32 -bit heltal, og fortolk dette tal som antallet af sekunder siden 00:00:00 UTC den 1. januar 1970."

Hvorfor opstår det, og hvad sker der, når det opstår?

Tider efter 03:14:07 UTC tirsdag den 19. januar 2038 vil 'ombrydes' og lagres internt som et negativt tal, hvilket disse systemer vil fortolke som et tidspunkt i 13. december 1901 frem for i 2038. Dette skyldes, at antallet af sekunder siden UNIX-epoken (1. januar) 1970 00:00:00 GMT) vil have overskredet en computers maksimale værdi for et 32-bit signeret heltal.

Hvordan løser vi det?

Brug lange datatyper (64 bit er tilstrækkeligt)
For MySQL (eller MariaDB), hvis du ikke har brug for tidsoplysningerne, kan du overveje at bruge DATE kolonnetype. Hvis du har brug for højere nøjagtighed, skal du bruge DATETIME i stedet for TIMESTAMP . Pas på at DATETIME kolonner gemmer ikke information om tidszonen, så din applikation skal vide, hvilken tidszone der blev brugt.
Andre mulige løsninger beskrevet på Wikipedia
Vent på, at MySQL-udviklere retter denne fejl rapporteret for over ti år siden.

Er der nogen mulige alternativer til at bruge det, som ikke udgør et lignende problem?

Prøv så vidt muligt at bruge store typer til at gemme datoer i databaser:64-bit er tilstrækkeligt - en lang lang type i GNU C og POSIX/SuS, eller sprintf('%u'...) i PHP eller BCmath-udvidelsen.

Hvad er nogle potentielt ødelæggende use cases, selvom vi endnu ikke er i 2038?

Så en MySQL DATETIME har et interval på 1000-9999, men TIMESTAMP har kun et interval på 1970-2038. Hvis dit system gemmer fødselsdatoer, fremtidige fremadrettede datoer (f.eks. 30 års realkreditlån) eller lignende, vil du allerede løbe ind i denne fejl. Igen, brug ikke TIMESTAMP, hvis dette bliver et problem.

Hvad kan vi gøre ved de eksisterende applikationer, der bruger TIMESTAMP, for at undgå det såkaldte problem, når det virkelig opstår?

Få PHP-applikationer vil stadig eksistere i 2038, selvom det er svært at forudse, da nettet næppe er en gammel platform endnu.

Her er en proces til at ændre en databasetabelkolonne for at konvertere TIMESTAMP til DATETIME . Det starter med at oprette en midlertidig kolonne:

# 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`

Ressourcer