В какой TimeZone хранить DateTime в БД?

Question

[Павел]

Веб-приложением будут пользоваться в разных часовых поясах.
В каком формате (часовой пояс) хранить поле с датой и временем в БД?

Как определять часовой пояс у клиента?
Я вижу 2 варианта:
1. Хранить в UTC, время определять на основании IP-адреса клиента.
2. Хранить в UTC, часовой пояс клиент выставляет руками в профиле.

Интересно, как хранят время в Facebook и Вконтакте?

Поделитесь своими практиками и идеями?
Может быть есть Best Practice?

Answer 1

[Max B]

Храните по гринвичу или москве — это не важно. Вам важно знать смещение у каждого пользователя.
Вот как это сделать:
var d = new Date()
var gmtHours = -d.getTimezoneOffset()/60;
console.log("The local time zone is: GMT " + gmtHours);


Answer 2

[Алексей Сундуков]

Храните в unix timestamp. При этом даже если на сервере будет неактуальная/поврежденная tzdata база (злоключения данной базы я думаю помним все), то данные в базу уйдут корректными. Если же привязываться к зонам, то всегда есть шанс, что формирование даты будет выполнено некорректно и некорректно же запишется в базу.

Comments

[Андрей Ширяев]

А как это поможет? unix timestamp — это дата с начала эпохи по сейчас, а это сейчас берется также на сервере из текущего времени. По этому если проблемы с tzdata, то дата все-равно выйдет некорректной.

К тому же не ясно какие даты собирается хранить автор может там даты за 1900г.

[Алексей Сундуков]

Нет, не выйдет. Конечно, время на сервере на момент запуска должно быть выставлено корректно. Учитывая зачастую поднятый по дефолту NTP это именно так и есть. Поэтому unix time в них корректный выставлен. А вот данные полученные в других форматах через tzdata могут оказаться некорректными при неактуальности последней. Если писать в базу что-то отличное от unix timestamp, то в базу пойдут некорректные записи которые исправить получиться только зная величину этой ошибки на момент записи. Если же писать в unix timestamp, то после того как будет поправлена tzdata, выдача даты из базы станет корректной, ведь в базе дата записана была корректно.

Если же на сервере время выставлено изначально криво, то уже не важно, в каком формате писать дату и кривая или нет tzdata. Запись в базу уйдет кривой в любом случае. Поэтому запись в формате unix timestamp это не панацея, но этот метод более устойчив к возможным ошибкам. К примеру, берем переход на летнее/зимнее время и админа, который забыл обновить tzdata. При unix timestamp данные в базу кривыми не уйдут.

Не говоря уже про в базе обычно этот тип требует под себя меньше объема.

Answer 3

[helions8]

Хранить в UTC, при регистрации/первом входе подставлять TZ клиента по IP, далее использовать сохраненный.

Comments

[Павел]

Есть ли в свободном доступе база диапазонов ip-адресов и TZ к которым они относятся?

[Max B]

Есть возможность узнать это через JS:
var d = new Date()
var tza = d.toLocaleString().split(" ").slice(-1)
var tzo = d.getTimezoneOffset()

Не нужно хранить сопоставления на сервере.

Answer 4

[Анатолий]

Не знаю как другие, но контакт хранит (и высчитывает) даты по своему (моссковскому?) времени, это заметно при действиях с датами (вычитание, сложение итд) Если каждый будет хранить по своему, это может быть чревато, выберите один формат и потом приводите его к пользовательскому (по айпи или профилю не важно, а помжно и так и так)

Comments

[Владимир Чернышев]

Мало того, его API возвращает часовой пояс +3 для Питера (или для чего он там возвращает). Писал им об этом баге, дня три ждал ответа, не дождался, плюнул и сделал $user_tz = $user_vk_tz+1;

Answer 5

[Владимир Чернышев]

>Не нужно хранить сопоставления на сервере.

Дополнительные сложности. Мало того, что нужен скрипт, который будет парсить все таймстампы на странице и преобразовывать их локально (а если NoScript стоит?), так ещё нужно локальную tz отправлять в запросах, связанных со временем.

Мне видится оптимальным хранить в timestamp/UTC, пояс пользователя в профиле/куках, а при несовпадении с сохраненным определенного локально JS спрашивать «У вас в настройках сайта часовой пояс +4, а в настройках вашего компа +12. Скорректировать настройки сайта в соответствии с локальными?»

Comments

[Max B]

Вы понимаете что делает js который я привел?
Я указал автору, что сопоставления ip_range=>timezone ему хранить не нужно, а timezone он может получить через js.
Что он будет делать с этим значением? Скорее всего он запишет его при регистрации и/или будет сравнивать корректны ли значения timezone из профиля и текущие пользовательские. Если нет, то это повод спросить об изменении местоположения и часового пояса в частности.
Вы написали: Мало того, что нужен скрипт, который будет парсить
Зачем чего парсить-то? У нас есть date_default_timezone_set() для глобальных настроек — и все DateTime, date конструкции будут возвращать корректные значения, либо у нас есть модель, которая может приводить эту дату в нужное соответствие.

Answer 6

[Fastto]

а можно не заморачиваться и при инициализации с БД устанавливать текущий часовой пояс клиента.
т.е. заходит чел с часовым поясом +4, ты SET TIME_ZONE = '+04:00' в БД сразу после создания соединения делаешь и работаешь без единой мысли о всяких конверсиях,
в итоге каждый согласно своим настройкам работает в своем часовом поясе.

проблема с неавторизованными — ну тут помогает предыдущий комментатор.
изначально устанавливаешь дефолтный серверный пояс, по загрузке JS корректирует его локальным пользовательским и храним в куках до авторизации/регистрации.

Comments

[Max B]

А что вы делаете с кешем комментариев, отзывов, статей?