26 August 2011

Doctrine 2 — дата и время

Столкнулся с проблемой использования типа datetime из Doctrine 2 и MySQL. Точнее, вот с чем: для временных меток я, естественно, хотел использовать MySQL'овский TIMESTAMP, который поддерживает временные зоны и хранит всё правильным образом. Но в Doctrine 2 datetime идёт в MySQL только как DATETIME, т.е. поддержки TIMESTAMP вообще нет.

И тут я стал думать :)

Сначала, естественно, о том, как вкрячить TIMESTAMP. И меня очень удивило, почему никто этого до сих пор не сделал.

А потом я подумал (не без помощи @magazoll) в другом направлении. Ведь база должна быть тупым хранилищем (в нашем случае). Почему бы тогда просто не хранить в БД тот же DATETIME, только время там держать в UTC+0. Т.е. в модели держать время в UTC+0. А уже при выводе или другой обработке конвертить в правильную зону, которая у пользователя.

Обосрите вариант.

6 comments:

Артур Тагиров said...

так TIMESTAMP тоже не содержит в себе часового пояса. И что значит засунуть в MySQL datetime, а не timestamp?

Unknown said...

При соединение с MYSQL ты прописываешь временную зону (либо она берётся по умолчанию из настроек сервера). Когда ты вставляешь в TIMESTAMP-поле какое-то значение, оно переводится из временной зоны твоего текущего соединения в UTC, и уже в UTC сохраняется в MySQL. Т.е. MySQL берёт на себя заботы о часовых поясах в случае использования TIMESTAMP-полей.

Unknown said...

Working with DateTime Instances — нашёл уже после публикации своей заметки. Собственно, тут и описано, как работать с временными зонами в приложении.

Anonymous said...

У меня возникла такая же проблема (в связи с переходом на ORM Doctrine 2), правда у меня DATETIME :)
и так уж исторически сложилось что в текущем проекте дата сохранялась в БД с преобразованием даты в зону GMT.
И тоже натолкнулся на эту статью.
Однако меня беспокоит тот факт, что преобразование даты из одной зоны в другую в PHP - довольно затратная операция (как по ресурсам так и по времени выполнения)
раньше все эти преобразования у меня осуществлялись в запросе.
Есть ли смысл тревожится по этому поводу?

Unknown said...

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

Проверьте, если сильно беспокоитесь.

elnur said...

@Column(type="datetimetz")

Не знаю насчёт MySQL, но с timestamptz в PostgreSQL работает отлично.