PHP/MySQL - сохранение дат для использования с отчетами о выборе даты в часовых поясах

в настоящее время обсуждает наилучший способ продолжения хранения даты и ценит опытные комментарии - ищет "почему", а не "как".

Сценарий:

Мы разрабатываем систему, которая позволяет клиентам (через несколько часовых поясов) создавать транзакционные данные. При регистрации клиент будет назначать свой часовой пояс. Большая часть системы вращается вокруг клиентских отчетов о дате и времени, связанных с транзакционными данными.

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

Наш вопрос: зачем идти на все проблемы с хранением в UTC - в чем преимущество хранения даты в UTC. С нашей точки зрения у нас есть часовой пояс, назначенный клиентом, поэтому, если мы храним дату/время в их правильном часовом поясе, тогда это расчет, который мы запускаем один раз за транзакцию, - после чего все их отчеты будут работать без каких-либо преобразований даты преобразования.

Поскольку большинство вопросов и комментариев, которые мы прочитали, относятся к "Как", мы считаем, что должно быть что-то о "Почему", которое мы пропустили.

Итак, вкратце, прежде чем мы сделаем наше решение, мы что-то упустили - есть ли абсолютная "необходимость хранения дат как причина UTC"?

Спасибо за чтение - любые комментарии оценены.

3 ответа

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


Зачем идти на все проблемы с хранением в UTC?

В UTC нет проблем с хранением времени. IMO легче поддерживать поля datetime, если они все находятся в одном и том же часовом поясе, а именно, что каждая запись таблицы, находящаяся в разных часовых поясах и отношение с таблицей user, сообщает вам, в какой временной зоне это поле (или даже абсурдным подходом было бы хранить смещение как +02:00 в дополнительном поле).

При регистрации клиент назначит свой часовой пояс.

Подумайте, что может случиться, когда вы добавите функциональные возможности:

  • Что делать, если пользователь изменяет часовой пояс?
  • Что делать, если вы обновите свою систему, чтобы пользователь мог указать часовой пояс для каждого запроса?
  • и др.

Существует ли абсолютная "дата сохранения в виде UTC"?

Ofc not; это все о вашем дизайне. То, что вы выбираете, - это то, с чем вы работаете; просто подумайте, что было бы проще для вас, для будущих обновлений и т.д.


На мой взгляд, было бы лучше сохранить даты/время как значение unix в базе данных. Затем у вас есть точный номер, который можно легко манипулировать, чтобы отображаться, как вам нравится, используя сохраненную часовую зону или иначе, и, что особенно важно, если вы решили изменить его представление, это будет быстро изменено.

licensed under cc by-sa 3.0 with attribution.