Миграция часового пояса PHP / MySQL

Question

У меня есть приложение, которое в настоящее время хранит метки времени в значениях MySQL DATETIME и TIMESTAMP. Однако приложение должно иметь возможность принимать данные от пользователей в нескольких часовых поясах и отображать временные метки в часовом поясе других пользователей. Таким образом, именно так я планирую внести изменения в заявку; Буду признателен за любые предложения по улучшению подхода.

Модификации базы данных

• Все TIMESTAMP будут преобразованы в значения DATETIME; это делается для обеспечения согласованности в подходе и для того, чтобы MySQL не пыталась делать умные вещи и конвертировать часовые пояса (я хочу сохранить преобразование в PHP, так как оно требует меньше изменений для приложения и будет более переносимым, когда мне в конце концов удастся побег из MySQL).
• Все значения DATETIME будут скорректированы для преобразования их в время UTC (в настоящее время все в австралийском EST)

Запрос модификаций

• Любое использование NOW () для замены на UTC_TIMESTAMP () в запросах, триггерах, функциях и т. Д.

Изменения в приложениях

• Приложение должно хранить часовой пояс и предпочтительный формат даты (например, США против остального мира)
• Все метки времени будут преобразованы в соответствии с настройками пользователя перед отображением
• Все введенные временные метки будут преобразованы в UTC в соответствии с настройками пользователя перед вводом

Дополнительные примечания

• Преобразование форматов будет выполняться на уровне приложений по нескольким основным причинам.
  • Подход к преобразованию часовых поясов варьируется от БД к БД, поэтому передача его там будет непереносимой (и я очень надеюсь, что когда-нибудь в ближайшем будущем уйду с MySQL).
  • В MySQL TIMESTAMP есть ограниченные диапазоны разрешенных дат (~ 1970–2038)
  • В MySQL TIMESTAMP есть и другие нежелательные атрибуты, в том числе причудливое поведение автообновления (если не тщательно отключено) и чувствительность к настройкам зоны сервера (и я подозреваю, что может испортить их при переходе на Amazon позже в этом году).
  • Выбор для изменения всех текущих значений даты и времени и использования UTC_TIMESTAMP () вместо NOW () состоит в том, чтобы избежать каких-либо проблем с настройками часового пояса сервера / соединения, которые могли бы изменить NOW (), но оставить UTC_TIMESTAMP () в покое; см. пример ниже.

Пример UTC_TIMESTAMP () против NOW ()

mysql> set time_zone = 'Australia/Canberra';
Query OK, 0 rows affected (0.06 sec)

mysql> select now(), utc_timestamp();
+---------------------+---------------------+
| now()               | utc_timestamp()     |
+---------------------+---------------------+
| 2010-06-06 14:31:36 | 2010-06-06 04:31:36 |
+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> set time_zone = 'America/Los_Angeles';
Query OK, 0 rows affected (0.00 sec)

mysql> select now(), utc_timestamp();
+---------------------+---------------------+
| now()               | utc_timestamp()     |
+---------------------+---------------------+
| 2010-06-05 21:31:43 | 2010-06-06 04:31:43 |
+---------------------+---------------------+
1 row in set (0.00 sec)

Есть ли что-то, чего мне здесь не хватает, или у кого-нибудь есть лучшие предложения для подхода?

Answer 1

Есть ли что-то, что я здесь упускаю, или у кого-нибудь есть лучшие предложения для подхода?

Возможно, вы делаете слишком много работы.

Пока вы знаете часовой пояс сохраненной временной метки, вы можете легко преобразовать ее в другой часовой пояс. Если вы используете современную версию PHP, встроенный класс DateTime включает в себя комплексное управление часовым поясом.

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

В противном случае ваш план кажется хорошо продуманным и завершенным.