В каком формате хранить метку времени?

Question

[Петруша Укропов]

Сейчас работаю над 2-мя проектами. В обоих есть манипуляции со временем и датами. И я никак не могу определится в каком формате хранить метку времени: unixtime или datetime?

С каким форматом лучше производить манипуляции, например: вычитать время или выбирать день между датами?

Answer 1

[cat_crash]

Я всегда использую unix timestamp. Это обычное целое число которым довольно просто манипулировать. Один недостаток — число 32 битное и имеет предел. Но этот предел пока даааалеко, и не думаю что ваш проект в первозданном виде достигнет этого предела.
DateTime удобен тем что он может хранить информацию о часовом поясе и сравнивать даты с учетом часовых поясов средствами MySQL.

Comments

[JustLuckyGuy]

Если быть точным, этой метки хватит до 2037 года

[Eddy_Em]

Хм, а что, где-то в линуксах time_t еще 32-битный?

Answer 2

[sirko_el]

Если Вы используете mysql — то ответ один: только unixtime.
Доводы:
1. База занимает меньше места.
2. Поля хорошо индексируются.
3. Работа с вычислениями ничуть не сложнее чем в случае с datetime.
4. Быстрее проходят операции над датами как на уровне базы так и на уровне бэкенда.
5. Значительно упрощается процесс форматирования и обработки при выводе.

Comments

[Артур Борденюк]

Как же быть в случае когда хочется хранить даты <1900, например, в _историческом_ проекте?

[Eddy_Em]

Если нужны даты в широком пределе, храните время в юлианских днях (double).

[weirdan]

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

Answer 3

[magicstream]

datetime — освобождает от привязки к текущей временной зоне сервера. допустим вы храните все даты в предопределенной временной зоне (например GMT), тогда при переносе базы на другой сервер — даты не пострадают.

timestamp — привязан к временной зоне сервера. если изменить временную зону сервера — то данные в поле изменяться соответственно.

код для проверки:

SET time_zone = '+00:00'; #ставим зону в GMT
CREATE TABLE `test_date_time` (  `dateime` DATETIME ,  `timestamp` TIMESTAMP ) ; # создаем таблицу
INSERT INTO `test_date_time`(`dateime`,`timestamp`) VALUES ( '2013-04-24 21:36:03','2013-04-24 21:36:03');  # вносим идентичные даты в оба поля
SET time_zone = '+05:00'; # меняем зону
SELECT * FROM test_date_time; # проверяем как выгдяет выборка

я за datetime.

функции манипуляции датами работают с timestamp и datetime идентично

Comments

[sirko_el]

Если вы над серьезными проектами работаете — то они будут работать как минимум на дедике, а там куда проще установить часовой пояс сервера, чем зоны менять туда-сюда.

[weirdan]

Текущая таймзона — это переменная соединения. Поэтому, если каждый клиент ее при соединении выставляет (как и должен), никуда таймштампы не поедут.

Кстати, если вы используете GMT offset, то вы не можете производить ряд арифметических операций с датами (например, добавить к дате полгода), поскольку неизвестны правила перехода на зимнее/летнее время. Поэтому предпочтительно использование olson db идентификаторов (таких как «Europe/Moscow»), и регулярное обновление базы таймзон с помощью mysql_tzinfo_to_sql.

Answer 4

[Андрей Шпак]

Я не специалист по mysql, просто системный администратор, однако я думаю, что в любом случае нужно использовать unixtime, так как это точное определение времени, без зависимости от конкретного часового пояса.

Для более подробных ответов я думаю требуется больше исходной информации.

Answer 5

[Владимир Пилипчук]

Все зависит от того, КАКИЕ манипуляции Вы планируете со временем роводить и КАКАЯ информация будет идти с датой для пользователя.
Это я вот к чему — напрмер я в одном проекте использую timestamp. так как для пользователя отдаю в виде — Статья опубликована три дня назад/неделю назад/годи три месяца назад и т.п. Мне как разработчику с timestamp проще.
Но если Вы собираетесь вычислять время, вроде аукционов — осталось 16 часов 23 минуты — то datetime будет рациональнее использовать.
Опять-же, писали выше, и так и так — одинаково работает, вопрос в удобстве.
Я не глубокий специалист в MySQL, но вроде бы он исходно даты хранит какраз в timestamp. Поправте если не прав.

Answer 6

[magicstream]

когда пользователи с разных поясов то и привязку времени приходится унифицировать. каждому свое.

Answer 7

[KEKSOV]

В дополнении к вышесказанному:

timestamp — время от начала эпохи, всегда указывается в UTC. При получении результатов запроса, например при помощи FROM_UNIXTIME( timestam поле ) учитывается временная зона сервера или указанная при помощи SET time_zone в рамках текущего соединения. Пример использования — у Вас чат-сервер или сервер по отслеживанию биржевых котировок, в базе для каждого события хранится timestamp события и, в зависимости от часовых поясов пользователей, можно отобразить их местное время этого события, просто указав в запросе соответствующую временную зону.

datetime не подвержен влиянию текущей временной зоны и более нагляден.

Что касается индексирования этих двух типов, то оно одинаково эффективно.

Еще инфа по теме была на Хабре.