Ich habe dies als Community-Wiki markiert, also zögern Sie nicht, es nach Belieben zu bearbeiten.
Was genau ist das Jahr-2038-Problem?
„Das Jahr-2038-Problem (auch bekannt als Unix Millennium Bug, Y2K38 in Analogie zum Y2K-Problem) kann dazu führen, dass einige Computersoftware vor oder im Jahr 2038 ausfällt. Das Problem betrifft alle Software und Systeme, die die Systemzeit als vorzeichenbehaftete 32 speichern -bit Integer, und interpretieren Sie diese Zahl als die Anzahl der Sekunden seit 00:00:00 UTC am 1. Januar 1970."
Warum tritt es auf und was passiert, wenn es auftritt?
Zeiten nach 03:14:07 UTC am Dienstag, 19. Januar 2038 wird „umlaufen“ und intern als negative Zahl gespeichert, die diese Systeme als eine Zeit im 13. Dezember 1901 und nicht im Jahr 2038 interpretieren. Dies liegt daran, dass die Anzahl der Sekunden seit der UNIX-Epoche (1 1970 00:00:00 GMT) den Maximalwert eines Computers für eine 32-Bit-Ganzzahl mit Vorzeichen überschritten haben.
Wie lösen wir es?
- Verwenden Sie lange Datentypen (64 Bit sind ausreichend)
- Für MySQL (oder MariaDB), wenn Sie die Zeitinformationen nicht benötigen, sollten Sie das
DATEverwenden Spaltentyp. Wenn Sie eine höhere Genauigkeit benötigen, verwenden SieDATETIMEstattTIMESTAMP. Beachten Sie, dassDATETIMESpalten speichern keine Informationen über die Zeitzone, daher muss Ihre Anwendung wissen, welche Zeitzone verwendet wurde. - Andere mögliche Lösungen auf Wikipedia beschrieben
- Warten Sie, bis MySQL-Entwickler diesen Fehler behoben haben vor über einem Jahrzehnt gemeldet.
Gibt es Alternativen zur Verwendung, die kein ähnliches Problem darstellen?
Versuchen Sie, wann immer möglich, große Typen zum Speichern von Daten in Datenbanken zu verwenden:64-Bit ist ausreichend - ein langer langer Typ in GNU C und POSIX/SuS oder sprintf('%u'...) in PHP oder der BCmath-Erweiterung.
Was sind einige potenziell bahnbrechende Anwendungsfälle, auch wenn wir noch nicht im Jahr 2038 sind?
Also ein MySQL DATETIME hat einen Bereich von 1000-9999, aber TIMESTAMP hat nur einen Bereich von 1970-2038. Wenn Ihr System Geburtsdaten, Zukunftsdaten (z. B. 30-jährige Hypotheken) oder ähnliches speichert, werden Sie bereits auf diesen Fehler stoßen. Auch hier gilt:Verwenden Sie TIMESTAMP nicht, wenn dies ein Problem darstellt.
Was können wir mit bestehenden Anwendungen tun, die TIMESTAMP verwenden, um das sogenannte Problem zu vermeiden, wenn es wirklich auftritt?
Im Jahr 2038 wird es nur noch wenige PHP-Anwendungen geben, obwohl es schwer vorhersehbar ist, da das Web noch kaum eine Legacy-Plattform ist.
Hier ist ein Prozess zum Ändern einer Datenbanktabellenspalte zum Konvertieren von TIMESTAMP bis DATETIME . Es beginnt mit dem Erstellen einer temporären Spalte:
# 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`
Ressourcen
