Как выбрать типы данных столбца MySQL, устойчивые к 2038 году?

Question

19 января, 2038 03:14:07 МСК сейчас менее чем через 20 лет.Это время, когда 32-разрядная метка времени UNIX переворачивается.Я работаю над созданием некоторых таблиц MySQL, которые могут все еще использоваться в то время.

Это так называемая проблема Year 2038 .

Похоже, из того, что я пробовал на MariaDB 10.3, использование типа данных TIMESTAMP дает ошибку 1292 (неверное значение даты и времени) для меток даты после смены даты.

Что такое хорошопрактика для разработки этих таблиц, чтобы быть перспективным?Я мог бы использовать DATETIME данные, но TIMESTAMP имеет некоторые очень полезные функции в отношении часовых поясов.

Есть ли вероятность, что какая-то будущая версия MySQL (не говоря уже о Linux и других производных UNIX) будет обновлена?

Answer 1

Вытащите код, который вы написали в 1998 году. Найдите машину, на которой он будет запущен.Вам может понадобиться найти дисковод гибких дисков для его загрузки.

Теперь спросите себя: «Что будет с кодом и оборудованием через 20 лет»?

Я предлагаю, чтобы, кроме государственных контрактов, всекод, написанный в 2018 году, будет в корзине задолго до 2038 года.

В 1998 году MySQL работал под управлением версии 3.xx;Я не хотел бы касаться этого 10-летним (или 20-летним) шестом.С тех пор внутренний формат DATETIME изменился, было добавлено CHARACTER SETs, добавлено много оптимизаций, добавлены подзапросы, исправлены ошибки и т. Д. И т. Д.

Моя точка зрения в этом последнем абзаце заключается в том, чтовсе, что вы напишете сегодня, претерпит изменения application по мере развития MySQL в течение следующих 20 лет.Исправление проблемы 2038 будет одним из многих изменений.

Answer 2

Используйте BigInts для хранения метки времени Unix. Это функционально эквивалентно типу TIMESTAMP, хотя в нем нет сахара, который к нему присоединен. Однако, если на уровне приложения вы просто хотите использовать временные метки UNIX, это вообще не имеет значения и, по крайней мере, для меня пока что тривиально обрабатывать на уровне базы данных случайные UNIX_TIMESTAMP (…) / FROM_UNIXTIME ( …) вызов. Это позволит вам продвинуться далеко за пределы 2038 года.

Хотя я ожидаю, что моб MySQL / Maria создаст некоторый хак в версии X.y, который автоматически обновит поля TimeStamp как часть пути обновления. Это, вероятно, будет выпущено 18 января 2038 года. ;)

Во всяком случае, если вы хотите, чтобы будущее было подтверждено, BIGINT рассматривается как метка времени UNIX, ваш ответ.