Стоит ли бояться проблемы 2038 года и не использовать timestamp?

Question

[Алексей Николаев]

Доброго вечера.
Как известно, формат TIMESTAMP имеет предел, который очень скоро наступит, и для некоторых секторов веб-разработки (например, недвижимость) это может быть весьма критично. В то же время, отказываться от этого формата в пользу константного DATETIME с возможными плясками вокруг временных зон и их конвертации друг в друга не хочется.

Стоит ли избегать использования этого формата сейчас? И самое главное - как определить, поддерживаются ли в системе (версии ПO, PHP, драйверов БД и прочего) 64-битные timestamp'ы, лишенные фактического ограничения?

Спасибо.

Comments

[Алексей Николаев]

Александр А: а если на сайте даты больше 2038? Например, банковская сфера, или недвижимость. Допустим, драйвер БД поддерживает такие большие значения, и все запишется, а при обработке какой-то дряхлый модуль этого не поймет и выдаст 1901 год, этот баг будет практически невозможно отловить.

[Алексей Николаев]

Александр А: в том и суть, что datetime не хочется использовать, т.к. лишний геморрой и почти наверняка будут баги.

[Алексей Николаев]

Александр А: есть, узнать, поддерживается ли в экосистеме проекта 64-битные timestamp's. В windows 8 и выше гарантированно поддерживаются, например, но это не веб.

[Котик Антон]

Боюсь, сегодня вы будете очень плохо спать, но просто не могу утаить это от вас - от проблемы 10000-01-01 00:00:00 вас даже DATETIME не спасёт.

Answer 1

[HiIamRobot]

Большинство веб проектов закрываются в первый год. В следующий ещё и в последующие годы. Если ваш доживет до 2038 это будет чудо, ещё с большей вероятностью не вы будете его рефакторить через 22 года(если он доживет). К этому времени его с 100% вероятностью перепишут на чем то другом, тут не знаешь чего через год два от веба ждать, а вы в такую даль смотрите.

Comments

[Алексей Николаев]

В том-то и суть, что не в даль. Если человек сейчас введет дату 2040 год (срок закрытия счета, или дата окончания инвестиций), то в худшем случае будут problemes.

[HiIamRobot]

Алексей Николаев: тогда ваш вопрос не имеет смысла. Вы сами на него ответили.

[Довольный Айтишникъ]

Алексей Николаев: если вы видите очевидную проблем и понимаете ее источник то вполне логично что этот тип поля Вам никак не подходит.

Answer 2

[xmoonlight]

Думаю, что поле - нужно делать обычным способом timestamp для базы данных (никаким не пользовательским!).
Потом сервер mysql и сам PHP проапдейтят и они сами расширят ограничения и в код, и в базу не надо будет лезть и ничего там править.

Answer 3

[Everything_is_not_so_bad]

Зависит от того, на какой цикл поддержки идет расчет. Но я сомневаюсь, что веб-системы могут существовать так долго без апгрейда.

Answer 4

[Андрей Павленко]

Вы вспомните, какая разработка была 20 лет назад. Да 20 лет назад люди об интернете не знали, только "избранные". Представьте, что будет через 20 лет? Волноваться о проблеме не стоит.
А если на сайте нужно ввести дату - используйте поле date в MySQL, оно поддерживает большой диапазон дат.