Как хранить время в UTC и местном часовом поясе

Question

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

Как правило, пользователи хотят иметь возможность запрашивать (по собственному местному времени) данные, собранные из систем в различных часовых поясах. Но иногда они хотят знать, что данные были созданы, скажем, в 18:00 в исходной системе. Это помогает, когда пользователи из разных уголков мира сообщают об одном и том же событии.

User1: What? We don't have any data for 20:00
User2: Dude, it says 20:00 right there on my screen.
User1: Wait, what timezone are you? What's the UTC-time?
User2: What is UTC? Is that something with computers?
User1: OMFG! *click*

Я ищу совет о том, как хранить данные.

Я думаю о сохранении всех дат и времени в UTC и добавлении дополнительного столбца, содержащего исходное имя часового пояса, в форме, позволяющей мне использовать mysql CONVERT_TZ или аналог в Java. Затем приложение конвертирует введенные пользователем даты в UTC, и я легко могу запросить базу данных. Все даты также могут быть легко преобразованы в местное время пользователей в приложении. Используя исходный столбец часового пояса, я также смогу отобразить исходную дату и время.

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

start_time_utc datetime
start_time_tz  varchar(64)
end_time_utc   datetime
end_time_tz    varchar(64)

Я на правильном пути?

Кто-нибудь, кто работал с такими данными, поделится своим опытом?

(я буду использовать MySQL 5.5 CE)

Обновление 1

Данные будут доставляться в XML-файлах, где каждая запись имеет дату и время в некотором местном часовом поясе. Таким образом, будет только один процесс вставки, выполняющийся в одном месте.

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

Answer 1

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

Answer 2

В руководстве есть раздел только для этого о отметке времени:

Значения TIMESTAMP преобразуются из текущего часового пояса в UTC для хранения и преобразуются обратно из UTC в текущий часовой пояс для извлечения,(Это происходит только для типа данных TIMESTAMP, но не для других типов, таких как DATETIME.) По умолчанию текущим часовым поясом для каждого соединения является время сервера.Часовой пояс можно установить для каждого соединения, как описано в разделе 9.6 «Поддержка часовых поясов MySQL Server».Пока настройка часового пояса остается постоянной, вы получаете то же значение, которое храните.Если вы сохраните значение TIMESTAMP, а затем измените часовой пояс и получите значение, полученное значение будет отличаться от значения, которое вы сохранили.Это происходит потому, что один и тот же часовой пояс не использовался для преобразования в обоих направлениях.Текущий часовой пояс доступен как значение системной переменной time_zone.

http://dev.mysql.com/doc/refman/5.5/en/timestamp.html

Таким образом, вы можете использовать: SET time_zone = timezone; на клиенте для установки часового пояса.Тогда все запросы будут переводить метку времени в правильный часовой пояс.Не нужно делать ничего сложного в Java, кроме установки часового пояса (я думаю, что это может быть даже параметр в строке подключения JDBC)

Answer 3

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