Я отметил это как вики сообщества, поэтому не стесняйтесь редактировать на досуге.
Что именно является проблемой 2038 года?
"Проблема 2038 года (также известная как Unix Millennium Bug, Y2K38 по аналогии с проблемой 2000 года) может привести к сбою некоторых компьютерных программ до или в 2038 году. Эта проблема затрагивает все программное обеспечение и системы, которые хранят системное время как 32-разрядное целое число со знаком и интерпретирует это число как количество секунд с 00:00:00 UTC 1 января 1970 года. "
Почему это происходит и что происходит, когда это происходит?
Время после 03: 14: 07 UTC во вторник, 19 января 2038 года будет «обернут» и будет храниться внутри как отрицательное число, которое эти системы будут интерпретировать как время 13 декабря 1901 года. а не в 2038 году. Это связано с тем, что количество секунд, прошедших с начала UNIX (1 января 1970 года, 00:00:00 по Гринвичу), превысило максимальное значение компьютера для 32-разрядного целого числа со знаком.
Как мы решаем это?
- Использовать длинные типы данных (достаточно 64 бита)
- Для MySQL (или MariaDB), если вам не нужна информация о времени, рассмотрите возможность использования типа столбца
DATE. Если вам нужна более высокая точность, используйте DATETIME вместо TIMESTAMP. Помните, что в столбцах DATETIME не хранится информация о часовом поясе, поэтому ваше приложение должно знать, какой часовой пояс использовался.
- Другие возможные решения, описанные в Википедии
- Подождите, пока разработчики MySQL исправят эту ошибку , о которой сообщалось более десяти лет назад.
Существуют ли возможные альтернативы его использованию, которые не представляют аналогичной проблемы?
Попробуйте по возможности использовать большие типы для хранения дат в базах данных: достаточно 64-битного типа - длинный длинный тип в GNU C и POSIX / SuS или sprintf('%u'...) в PHP или расширение BCmath.
Каковы некоторые потенциально опасные варианты использования, хотя мы еще не в 2038 году?
Таким образом, MySQL DATETIME имеет диапазон 1000-9999, а TIMESTAMP имеет диапазон только 1970-2038. Если ваша система хранит даты рождения, будущие форвардные даты (например, 30-летние ипотеки) или аналогичные, вы уже столкнетесь с этой ошибкой. Опять же, не используйте TIMESTAMP, если это будет проблемой.
Что мы можем сделать с существующими приложениями, которые используют TIMESTAMP, чтобы избежать так называемой проблемы, когда она действительно возникает?
Мало PHP-приложений появятся в 2038 году, хотя это трудно предвидеть, поскольку Интернет пока еще не является устаревшей платформой.
Вот процесс изменения столбца таблицы базы данных для преобразования TIMESTAMP в DATETIME. Он начинается с создания временного столбца:
# 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`
Ресурсы