PHP &mySQL:jaar 2038 Bug:wat is het? Hoe het op te lossen?

Ik heb dit gemarkeerd als een community-wiki, dus voel je vrij om het op je gemak te bewerken.

Wat is precies het jaar 2038-probleem?

"Het jaar 2038-probleem (ook bekend als Unix Millennium Bug, Y2K38 naar analogie van het Y2K-probleem) kan ertoe leiden dat sommige computersoftware voor of in het jaar 2038 uitvalt. Het probleem treft alle software en systemen die systeemtijd opslaan als een ondertekend 32 -bit integer, en interpreteer dit getal als het aantal seconden sinds 00:00:00 UTC op 1 januari 1970."

Waarom gebeurt het en wat gebeurt er als het gebeurt?

Tijden na 03:14:07 UTC op dinsdag 19 januari 2038 zal 'omwikkelen' en intern worden opgeslagen als een negatief getal, dat deze systemen zullen interpreteren als een tijd in 13 december 1901 in plaats van in 2038. Dit komt door het feit dat het aantal seconden sinds het UNIX-tijdperk (1 januari 1970 00:00:00 GMT) de maximale waarde van een computer voor een 32-bits geheel getal met teken heeft overschreden.

Hoe lossen we het op?

Gebruik lange gegevenstypen (64 bits is voldoende)
Voor MySQL (of MariaDB), als u de tijdinformatie niet nodig heeft, overweeg dan om de DATE te gebruiken soort kolom. Als u een hogere nauwkeurigheid nodig heeft, gebruikt u DATETIME in plaats van TIMESTAMP . Pas op dat DATETIME kolommen slaan geen informatie over de tijdzone op, dus uw applicatie zal moeten weten welke tijdzone is gebruikt.
Andere mogelijke oplossingen beschreven op Wikipedia
Wacht tot MySQL-ontwikkelaars deze bug hebben opgelost meer dan tien jaar geleden gemeld.

Zijn er mogelijke alternatieven voor het gebruik, die geen soortgelijk probleem opleveren?

Probeer waar mogelijk grote typen te gebruiken voor het opslaan van datums in databases:64-bits is voldoende - een lang, lang type in GNU C en POSIX/SuS, of sprintf('%u'...) in PHP of de BCmath-extensie.

Wat zijn enkele potentieel baanbrekende use-cases, ook al zijn we nog niet in 2038?

Dus een MySQL DATETIME heeft een bereik van 1000-9999, maar TIMESTAMP heeft alleen een bereik van 1970-2038. Als uw systeem geboortedata, toekomstige datums (bijv. 30-jarige hypotheken) of iets dergelijks opslaat, loopt u al tegen deze bug aan. Nogmaals, gebruik TIMESTAMP niet als dit een probleem gaat worden.

Wat kunnen we doen aan de bestaande applicaties die TIMESTAMP gebruiken, om het zogenaamde probleem te voorkomen, wanneer het zich echt voordoet?

Er zullen nog maar weinig PHP-applicaties zijn in 2038, hoewel het moeilijk te voorzien is omdat het web nog nauwelijks een legacy-platform is.

Hier is een proces voor het wijzigen van een databasetabelkolom om TIMESTAMP te converteren tot DATETIME . Het begint met het maken van een tijdelijke kolom:

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

Bronnen