PHP & mySQL: Jahr 2038 Fehler: Was ist das? Wie man es löst?

Ich habe darüber nachgedacht, TIMESTAMP zum Speichern von Datum und Uhrzeit zu verwenden, aber ich habe gelesen, dass es eine Beschränkung für das Jahr 2038 gibt. Anstatt meine Frage in großen Mengen zu stellen, habe ich es vorgezogen, sie in kleine Teile aufzuteilen, damit sie auch für Anfänger leicht verständlich sind. Also meine Frage (n):

1. Was genau ist das Problem des Jahres 2038?
2. Warum tritt es auf und was passiert, wenn es auftritt?
3. Wie lösen wir das?
4. Gibt es mögliche Alternativen zur Verwendung, die kein ähnliches Problem darstellen?
5. Was können wir mit den vorhandenen Anwendungen tun, die TIMESTAMP verwenden, um das sogenannte Problem zu vermeiden, wenn es tatsächlich auftritt?

Danke im Voraus.

Ich habe dies als Community-Wiki markiert. Sie können es also nach Belieben bearbeiten.

Was genau ist das Problem des Jahres 2038?

"Das Problem des Jahres 2038 (analog zum Y2K-Problem auch als Unix Millennium Bug, Y2K38 bekannt) kann dazu führen, dass einige Computersoftware vor oder im Jahr 2038 ausfällt. Das Problem betrifft alle Software und Systeme, in denen die Systemzeit als signierte 32 gespeichert ist -bit Ganzzahl, 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 jenseits 03:14:07 UTC am Dienstag, 19. Januar 2038, werden " umlaufen " und intern als negative Zahl gespeichert, die diese Systeme als Zeit am 13. Dezember 1901 und nicht im Jahr 2038 interpretieren. Dies ist darauf zurückzuführen Die Tatsache, dass die Anzahl der Sekunden seit der UNIX-Epoche (1. Januar 1970, 00:00:00 GMT) den Maximalwert eines Computers für eine 32-Bit-Ganzzahl mit Vorzeichen überschritten hat.

Wie lösen wir das?

• Verwenden Sie lange Datentypen (64 Bit sind ausreichend)
• Wenn Sie für MySQL (oder MariaDB) keine Zeitinformationen benötigen, sollten Sie den DATESpaltentyp verwenden. Wenn Sie eine höhere Genauigkeit benötigen, verwenden Sie DATETIMEstatt TIMESTAMP. Beachten Sie, dass in DATETIMESpalten keine Informationen zur Zeitzone gespeichert werden, sodass Ihre Anwendung wissen muss, welche Zeitzone verwendet wurde.
• Andere mögliche Lösungen auf Wikipedia beschrieben
• Warten Sie, bis MySQL-Entwickler diesen vor über einem Jahrzehnt gemeldeten Fehler behoben haben.

Gibt es mögliche Alternativen zur Verwendung, die kein ähnliches Problem darstellen?

Versuchen Sie nach Möglichkeit, 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 brechende Anwendungsfälle, obwohl wir noch nicht im Jahr 2038 sind?

Ein MySQL DATETIME hat also einen Bereich von 1000-9999, aber TIMESTAMP hat nur einen Bereich von 1970-2038. Wenn Ihr System Geburtsdaten, zukünftige Termine (z. B. 30-jährige Hypotheken) oder ähnliches speichert, wird dieser Fehler bereits auftreten. Verwenden Sie auch hier nicht TIMESTAMP, wenn dies ein Problem darstellen soll.

Was können wir mit den vorhandenen Anwendungen tun, die TIMESTAMP verwenden, um das sogenannte Problem zu vermeiden, wenn es tatsächlich auftritt?

Im Jahr 2038 werden es nur noch wenige PHP-Anwendungen geben, obwohl dies schwer vorhersehbar ist, da das Web noch kaum eine Legacy-Plattform ist.

Hier ist ein Prozess zum Ändern einer Datenbanktabellenspalte, in die konvertiert werden TIMESTAMPsoll 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

• Jahr 2038 Problem (Wikipedia)
• Das Internet wird in 30 Jahren enden

Wenn Sie UNIX-Zeitstempel zum Speichern von Datumsangaben verwenden, verwenden Sie tatsächlich 32-Bit-Ganzzahlen, die die Anzahl der Sekunden seit dem 01.01.1970 zählen. Siehe Unix-Zeit

Diese 32-Bit-Zahl wird 2038 überlaufen. Das ist das 2038-Problem.

Um dieses Problem zu lösen, dürfen Sie zum Speichern Ihrer Daten keinen 32-Bit-UNIX-Zeitstempel verwenden. Wenn Sie also MySQL verwenden, sollten Sie nicht verwenden TIMESTAMP, aber DATETIME(siehe 10.3.1. Die Typen DATETIME, DATE und TIMESTAMP ):

Der DATETIMETyp wird verwendet, wenn Sie Werte benötigen, die sowohl Datums- als auch Zeitinformationen enthalten. Der unterstützte Bereich ist '1000-01-01 00:00:00'zu '9999-12-31 23:59:59' .

Der TIMESTAMPDatentyp hat einen Bereich von '1970-01-01 00:00:01'UTC bis '2038-01-19 03:14:07'UTC.

Das (wahrscheinlich) Beste, was Sie mit Ihrer Anwendung tun können, um dieses Problem zu vermeiden / zu beheben, ist, es nicht zu verwenden TIMESTAMP, aberDATETIME für die Spalten, die Daten enthalten müssen, die nicht zwischen 1970 und 2038 liegen.

Ein kleiner Hinweis: Es gibt eine sehr hohe Wahrscheinlichkeit (statistisch gesehen), dass Ihre Bewerbung vor 2038 einige Male neu geschrieben wurde ^^ Vielleicht also, wenn Sie sich in Zukunft nicht mit Daten befassen müssen müssen Sie sich mit der aktuellen Version Ihrer Anwendung nicht um dieses Problem kümmern ...

Eine schnelle Suche bei Google reicht aus: Problem Jahr 2038

1. Das Problem des Jahres 2038 (in Analogie zum Y2K-Problem auch als Unix Millennium Bug, Y2K38 bekannt) kann dazu führen, dass einige Computersoftware vor oder im Jahr 2038 ausfällt
2. Das Problem betrifft alle Software und Systeme, die die Systemzeit als vorzeichenbehaftete 32-Bit-Ganzzahl speichern und diese Zahl als die Anzahl der Sekunden seit 00:00:00 UTC am 1. Januar 1970 interpretieren. Die späteste Zeit, die auf diese Weise dargestellt werden kann ist 03:14:07 UTC am Dienstag, 19. Januar 2038. Zeiten, die über diesen Moment hinausgehen, werden "umlaufen" und intern als negative Zahl gespeichert, die diese Systeme als Datum im Jahr 1901 und nicht im Jahr 2038 interpretieren
3. Es gibt keine einfache Lösung für dieses Problem für vorhandene CPU / OS-Kombinationen, vorhandene Dateisysteme oder vorhandene binäre Datenformate

http://en.wikipedia.org/wiki/Year_2038_problem enthält die meisten Details

Zusammenfassend:

1) + 2) Das Problem ist, dass viele Systeme Datumsinformationen als 32-Bit-Int mit Vorzeichen speichern, was der Anzahl der Sekunden seit dem 1.1.1970 entspricht. Das letzte Datum, das so gespeichert werden kann, ist 03:14:07 UTC am Dienstag, den 19. Januar 2038. In diesem Fall wird der int "umbrochen" und als negative Zahl gespeichert, die als Datum im Jahr 1901 interpretiert wird. Was genau dann passieren wird, variiert von System zu System, aber es reicht zu sagen, dass es wahrscheinlich für keinen von ihnen gut sein wird!

Für Systeme, die nur Daten in der Vergangenheit speichern, müssen Sie sich wohl eine Weile keine Sorgen machen! Das Hauptproblem sind Systeme, die in Zukunft mit Daten arbeiten. Wenn Ihr System in 28 Jahren mit Daten arbeiten muss, sollten Sie sich jetzt Sorgen machen!

3) Verwenden Sie eines der verfügbaren alternativen Datumsformate oder wechseln Sie zu einem 64-Bit-System und verwenden Sie 64-Bit-Ints. Oder verwenden Sie für Datenbanken ein alternatives Zeitstempelformat (z. B. für MySQL verwenden Sie DATETIME).

4) Siehe 3!

5) Siehe 4 !!! ;)

Bros, wenn Sie PHP zum Anzeigen von Zeitstempeln verwenden müssen, ist dies die BESTE PHP-Lösung, ohne vom UNIX_TIMESTAMP-Format zu wechseln.

Verwenden Sie eine custom_date () -Funktion. Verwenden Sie darin die DateTime. Hier ist die DateTime-Lösung .

Solange Sie UNSIGNED BIGINT (8) als Zeitstempel in der Datenbank haben. Solange Sie PHP 5.2.0 ++ haben

Da ich nichts aktualisieren wollte, bat ich mein Backend (MSSQL), diesen Job anstelle von PHP zu erledigen!

$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'];

Vielleicht kein effizienter Weg, aber es funktioniert.