Время UTC в таблицах SQL

Question

Столбцы, такие как CreatedDate и ModifiedDate, обычно используются в таблицах SQL. Я думаю, что сохранение значения времени UTC поможет устранить зависимость от расположения сервера, на котором размещено приложение. Благодаря знакомству с облачными вычислениями (даже исключая их) приложения могут размещаться в любом часовом поясе и в любой части мира.

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

Правильно ли мыслительный процесс? Есть ли минусы в этом подходе? Разве проще хранить время, определенное для зоны?

Цените свои мысли!

Answer 1

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

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

Answer 2

SQL 2008 имеет тип данных с именем datetimeoffset, который также может хранить часовой пояс. Это означает, что вы можете съесть свой торт и съесть его!

Вам, скорее всего, нужно сохранить версию UTC, потому что в противном случае у вас есть "который 2:30 был?" когда происходит летнее время. Но с datetimeoffset вы в порядке.

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

Интересно, что Митч Уит (оставивший комментарий к вашему вопросу) живет в Перте, который только недавно ввел летнее время. Я написал блог об этом на: http://msmvps.com/blogs/robfarley/archive/2006/10/25/The-horror-of-daylight-savings-_2800_sorry-Perth_2900_.aspx

Итак, посмотрите, как вы идете. Я бы определенно рекомендовал datetimeoffset, чтобы вы могли показать, что время сохранялось как 5 вечера в летнее время.

Rob