PHP i mySQL:Rok 2038 Błąd:Co to jest? Jak to rozwiązać?

Oznaczyłem to jako wiki społecznościowe, więc możesz je edytować w wolnym czasie.

Czym dokładnie jest problem roku 2038?

„Problem roku 2038 (znany również jako Unix Millennium Bug, Y2K38 przez analogię do problemu Y2K) może spowodować awarię niektórych programów komputerowych przed lub w roku 2038. Problem dotyczy wszystkich programów i systemów, które przechowują czas systemowy jako podpisany 32 -bitowa liczba całkowita i zinterpretuj tę liczbę jako liczbę sekund od 00:00:00 UTC 1 stycznia 1970 r."

Dlaczego to się dzieje i co się dzieje, gdy się pojawia?

Czasy po 03:14:07 UTC we wtorek, 19 stycznia 2038 „zawinie się” i będzie przechowywany wewnętrznie jako liczba ujemna, którą te systemy zinterpretują jako czas 13 grudnia 1901 r., a nie 2038 r. Wynika to z faktu, że liczba sekund od epoki UNIX-a (1 stycznia 1970 00:00:00 GMT) przekroczy maksymalną wartość komputera dla 32-bitowej liczby całkowitej ze znakiem.

Jak to rozwiążemy?

Używaj długich typów danych (wystarczy 64 bity)
W przypadku MySQL (lub MariaDB), jeśli nie potrzebujesz informacji o czasie, rozważ użycie DATE typ kolumny. Jeśli potrzebujesz większej dokładności, użyj DATETIME zamiast TIMESTAMP . Pamiętaj, że DATETIME kolumny nie przechowują informacji o strefie czasowej, więc Twoja aplikacja będzie musiała wiedzieć, która strefa czasowa została użyta.
Inne możliwe rozwiązania opisane w Wikipedii
Poczekaj, aż deweloperzy MySQL naprawią ten błąd zgłoszone ponad dekadę temu.

Czy są jakieś możliwe alternatywy dla jego używania, które nie stwarzają podobnego problemu?

W miarę możliwości staraj się używać dużych typów do przechowywania dat w bazach danych:wystarczy 64-bity — długi długi typ w GNU C i POSIX/SuS lub sprintf('%u'...) w PHP lub rozszerzeniu BCMath.

Jakie są potencjalnie przełomowe przypadki użycia, mimo że nie jesteśmy jeszcze w 2038 roku?

Tak więc MySQL DATETIME ma zakres 1000-9999, ale TIMESTAMP ma tylko zakres 1970-2038. Jeśli twój system przechowuje daty urodzenia, przyszłe daty przyszłe (np. 30-letnie kredyty hipoteczne) lub podobne, już natkniesz się na ten błąd. Ponownie, nie używaj TIMESTAMP, jeśli ma to stanowić problem.

Co możemy zrobić z istniejącymi aplikacjami, które używają TIMESTAMP, aby uniknąć tzw. problemu, kiedy naprawdę wystąpi?

Niewiele aplikacji PHP będzie nadal dostępnych w 2038 r., choć trudno to przewidzieć, ponieważ sieć nie jest jeszcze starszą platformą.

Oto proces zmiany kolumny tabeli bazy danych w celu konwersji TIMESTAMP do DATETIME . Zaczyna się od utworzenia tymczasowej kolumny:

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

Zasoby