Хранение DateTime (UTC) против хранения DateTimeOffset

Question

У меня обычно есть «перехватчик», который прямо перед чтением / записью из / в базу данных выполняет преобразование DateTime (из UTC в местное время и из местного времени в UTC), поэтому я могу использовать DateTime.Now (деривации и сравнения) во всей системе, не беспокоясь о часовых поясах.

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

Должен ли я продолжать хранить свои даты(SQL 2008 - дата-время) в формате UTC или я должен вместо этого хранить его, используя DateTimeOffset (SQL 2008 - datetimeoffset)?

UTC Даты в базе данных (тип datetime) работают и известны так долго,зачем это менять?Каковы преимущества?

Я уже просматривал статьи, подобные , эту , но я не уверен на 100%.Есть мысли?

Answer 1

Существует одно огромное отличие, когда вы не можете использовать UTC в одиночку.

• Если у вас есть такой сценарий

  • Один сервер и несколько клиентов (все географически в разных часовых поясах )
  • Клиенты создают некоторые данные с информацией о времени и дате
  • Клиенты хранят все это на центральном сервере

• Тогда:

  • datetimeoffset хранит время UTC и ТАКЖЕ смещение на местное время клиента
  • все клиенты знают UTC время всех данных, а также местное время в месте происхождения информации

• Но:

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

Простой пример - система бронирования авиабилетов ... Билет должен содержать 2 раза: - время «взлета» (в часовом поясе города «От») - время «посадки» (в часовом поясе города «Пункт назначения»)

Answer 2

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

Когда использовать местное время? Ответ на этот вопрос:

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

Храните только местное время, если ответ «да». Очевидно, что это будет только для будущих дат, и обычно только для дат, которые каким-то образом влияют на людей.

Зачем хранить часовой пояс / смещение?

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

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

Answer 3

DATETIMEOFFSET дает вам возможность хранить местное время и время UTC в одном поле.

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

Это два наиболее распространенных требования - местное время для локальных отчетов и время UTC для групповых отчетов.

Местное время сохраняется в части DATETIME в DATETIMEOFFSET, а OFFSET от UTC сохраняется в части OFFSET, поэтому преобразование является простым и, поскольку оно не требует знания часового пояса, из которого получены данные, все может быть выполнено на уровне базы данных.

Если вам не нужно время до миллисекунд, например всего за несколько минут или секунд, вы можете использовать DATETIMEOFFSET (0). В этом случае для поля DATETIMEOFFSET потребуется только 8 байтов памяти - то же самое, что и DATETIME.

Использование DATETIMEOFFSET вместо UTC DATETIME, таким образом, обеспечивает большую гибкость, эффективность и простоту отчетности.