Всегда ли рекомендуется хранить время в формате UTC или в этом случае лучше хранить время в местном масштабе?

Я думаю, что для ответа на этот вопрос мы должны подумать о преимуществах использования UTC для хранения временных меток.

Я лично считаю, что главное преимущество этого заключается в том, что время всегда (в основном) гарантированно согласовано. Другими словами, всякий раз, когда меняется часовой пояс или применяется летнее время, вы не перемещаетесь назад или вперед во времени. Это особенно полезно для файловых систем, журналов и так далее. Но это необходимо в вашем приложении?

Подумайте о двух вещах. Во-первых, о времени перехода часов на летнее время. Вероятно ли, что ваши события будут происходить между 2 и 3 часами ночи (в тот день, когда закончится сдвиг часов)? Что тогда должно произойти?

Во-вторых, будет ли приложение подвергаться действительным изменениям часового пояса? Другими словами, вы собираетесь лететь на нем из Лондона в Варшаву и соответствующим образом изменить часовой пояс вашего компьютера? Что должно произойти в таком случае?

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

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

Вы упомянули, что показываете время через API. Будет ли приложение запрашивать базу данных при каждом запросе? Если вы храните время внутри как UTC, вам нужно будет либо это сделать, либо иным образом убедиться, что при изменении летнего времени / часового пояса кэшированное время будет скорректировано / сокращено.

Будет ли оно что-нибудь делать с самим временем? Например, распечатать событие произойдет через 8 часов или приостановить себя примерно на это время? Если да, то вероятно UTC будет лучше. Конечно, нужно продумать все вышеперечисленные вопросы.

Мне нравится думать об этом так:

Компьютеры не заботятся о времени как о понятном человеку представлении. Их не волнуют часовые пояса, форматирование строки даты и времени или что-то еще. Только люди заботятся о том, как интерпретировать и представлять время.

Позвольте базе данных делать то, в чем она хороша: хранить время в виде числа - либо эпоху UNIX (количество секунд, прошедших с 01.01.1970), либо метку времени UTC (без информации о часовом поясе или летнем времени). Заботьтесь о представлении времени в понятной человеку форме только тогда, когда это необходимо. Это означает, что в логике вашего приложения, системе отчетности, консольном приложении или любом другом месте данные будут просматриваться человеком.

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

Сохранение в формате UTC - это нормально, но есть одно требование, которое вызывает боль, если вы это делаете: «Можете ли вы написать мне отчет, который покажет мне, сколько X происходит в день?»

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

Если ваше заявление соответствует следующим критериям:

1. Каждый экземпляр находится в одном часовом поясе.
2. Переходы между часовыми поясами обычно происходят в нерабочее время, или вы действительно не заботитесь о «продолжительности» вещей до того уровня, когда пропущенный час или около того будет иметь значение.

Я предлагаю вам сохранить datetime как местное время, используя библиотеку, которая изолирует вас от проблем с конфигурацией часового пояса сервера (например, Noda.Time в мире .net).

Если ваши межсистемные сообщения используют ISO 8601, а ваша база данных хранит местное время происхождения + смещение (например, datetimeoffset в MSSQL или ISODate в Mongo, поскольку ISO 8601 фиксирует его), и вы используете только DateTimeOffset в .NET или OffsetDateTime в Java или какой-либо эквивалент в вашем коде, тогда никаких преобразований не требуется. Вы просто храните это. Все функции сравнения будут работать.

Если вы конвертируете в UTC в своей настойчивости, вы теряете смещение с точки зрения пользователя. Отображение того, когда ваш пользователь подписал документ десять лет назад, теперь является сложной проблемой. Вычисление этого из UTC будет означать поиск правил DST, которые действовали в то время на этой территории. Кошмарный сон.

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

Я бы просто сохранил компонент Time без какой-либо зоны. Каждый раз, когда API должен его обслуживать, добавьте правильную дату и преобразуйте ее как местное время в UTC для этой даты.

База данных = 17:00 (используйте метку времени без даты, часы в байтах, минуты в байтах, строка)

Получить = Дата, где мы хотим событие + База данных 17:00 => Преобразовать это из локального в UTC

Таким образом, вы всегда будете показывать правильное время по всемирному координированному времени.

На самом деле вы не сохраняете конкретный момент времени, как предполагает большинство API времени. Используйте интервалы, если ваша база данных поддерживает это (PostgreSQL поддерживает), или сохраните их как целое число, представляющее количество секунд (минут / часов) с полуночи или соответствующего начала расписания (понедельник, первое число месяца и т. Д.). В любом случае вы избавились от многих головных болей, связанных с беспокойством о том, как «время» обрабатывается между системами, и добавили лишь очень незначительную головную боль, связанную с преобразованием секунд во время дня в вашем представлении.