2013-08-07 4 views
0

Я только что понял о проблеме 2038 года, когда время unix будет сброшено до отрицательного минимального диапазона, поэтому я решил сделать небольшое исследование для этой интересной темы.PHP - Сохранение timestamp unix в mysql (исключение переполнения time_t)

Сейчас я проектирование структуры базы данных (в MySQL), и я думаю, что эти два соображения могли бы решить эту проблему:

1) - Сохранение данных времени НЕ в поле метки времени, но в BIGINT (или больше).

2) - Сервер, который я буду использовать для моего приложения, использует 64-разрядную ОС, поэтому, если я использую функцию даты php, он вернет дату правильно.

Основываясь на тех соображениях, которые я собираюсь принять с помощью timestamp, что вы думаете об этом? Thank's ..

ответ

0

MySQL DATETIME колонки имеют диапазон до 9999-12-31 23:59:59, поэтому я бы предложил использовать их, а не TIMESTAMP, если вы беспокоитесь о проблеме Y2K38.

Единственное преимущество TIMESTAMP имеет более DATETIME - это автоматическое изменение часового пояса, но мы, как правило, сохраняем все наше время как UTC, так что это не проблема для нас.

Если вы действительно хотите использовать временные метки, то я почти уверен, там будут согласованные усилия задолго до 2038 для обновления системы MySQL и C к time_t, который имеет гораздо больший радиус действия. Так как он отличается от C, он будет довольно легко обновляться.

И, в отличие от плоских файлов на C, будет намного проще переносить данные базы данных просто потому, что метаданные столбца (такие как , которые содержат столбцы) легко доступны.

+0

Спасибо за ваш ответ, в начале я решил использовать временную метку, потому что сервер, на котором я использую (бесплатный хостинг), не имеет такой же часовой зоны, как у меня, поэтому быстрое решение может заключаться в том, чтобы сделать разницу во времени с php (отнять), а затем взять это время в качестве основы для всего (включая регистрацию через эту функцию), так что может быть возможное/достойное решение для того, чтобы сделать то же самое, но для datetime? – Neo

+0

@Neo, где наше приложение работает в другом часовом поясе, запросы просто корректируются в зависимости от элемента конфигурации. Другими словами, информация о времени от пользователя сдвигается в UTC как можно раньше, пока информация о времени пользователю переводится обратно в местную как можно позже. Но, см. Предпоследний абзац, это никогда не станет проблемой, потому что задолго до 2038 года базовый тип изменится, чтобы исправить это. – paxdiablo

+0

Я только что узнал, что есть функция mysql, называемая CONVERT_TZ, которая принимает 3 параметра, дату, часовой пояс и точку времени, вероятно, это мое лучшее решение :) – Neo