Каков практический способ хранения даты и времени, чтобы я мог позволить пользователям просматривать/запрашивать данные по своему собственному локальному времени, сохраняя при этом информацию об исходной дате и времени.
По сути, пользователи хотят иметь возможность запрашивать (по своему местному времени) данные, собранные из систем в разных часовых поясах. Но иногда они хотят знать, что данные были созданы, скажем, в 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, не их местное время.
DateTimeOffset
, как в MSSQL (тип данных, указывающий отметку времени и ее смещение от UTC)? Если это не так, то ваше решение является ближайшим эквивалентом, отличающимся только количеством необходимых полей (1 против 2). - person bzlm   schedule 10.01.2011TIMESTAMP WITH TIMEZONE
(это тип данных ANSI для этого) - person a_horse_with_no_name   schedule 10.01.2011