Хранение даты/времен как UTC в базе данных

Поправьте меня, если я ошибаюсь, но разве это не ошибка при сохранении времени в формате UTC?

Да, это так. Кроме того, дни корректировки будут иметь 23 или 25 часов, поэтому идиома предыдущего дня в то же время является местным временем - 24 часа неверно 2 дня в году.

Чтобы исправить это, нужно выбрать один стандарт и придерживаться его. Сохранение дат в формате UTC и отображение как локальных - это довольно стандартно. Просто не используйте ярлык для выполнения вычислений локально (+ - что-то) = новое время, и все в порядке.

Это огромный недостаток, но это не недостаток хранения времени в формате UTC (потому что это единственная разумная вещь - сохранение местного времени всегда катастрофа). Это недостаток концепции перехода на летнее время. Настоящая проблема в том, что информация о часовом поясе изменяется. Правила перехода на летнее время динамичны и историчны. Они время, когда переход на летнее время в США в 2010 году, отличается от того, когда оно началось в 2000 году. До недавнего времени Windows даже не содержала этих исторических данных, поэтому было практически невозможно делать что-то правильно. Вы должны были использовать базу данных tz , чтобы понять это правильно. Теперь я просто погуглил, и оказалось, что .NET 3.5 и Vista (я предполагаю, что и Windows 2008 тоже) внесли некоторые улучшения, а System.TimeZoneInfo фактически обрабатывает исторические данные. Взгляните на это .

Но в основном летнее время должно быть отменено.

Хорошо, что вы пытаетесь сохранить дату и время в формате UTC. Обычно лучше и проще думать о UTC как о фактической дате и времени, а местное время - это просто псевдонимы для этого. И UTC абсолютно критичен, если вам нужно выполнить какие-либо математические вычисления со значениями даты / времени, чтобы получить временные интервалы. Я обычно управляю датами внутри как UTC и конвертирую в местное время только при отображении значения пользователю (если это необходимо).

Ошибка заключается в том, что вы неправильно назначаете местный часовой пояс значениям даты / времени. В январе в Великобритании неправильно интерпретировать местное время как летнее. Вы должны использовать часовой пояс, который действовал в то время и в месте, которое представляет значение времени.

Перевод времени назад для отображения полностью зависит от требований системы. Вы можете отображать время как местное время пользователя или как исходное время для данных. Но в любом случае настройки перехода на летнее / летнее время должны применяться в соответствии с целевым часовым поясом и временем.

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

31/12/2009 23:00 +0100

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

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

Метод TimeZoneInfo.ConvertTimeFromUtc () решит вашу проблему:

using System;

class Program {
  static void Main(string[] args) {
    DateTime dt1 = new DateTime(2009, 12, 31, 23, 0, 0, DateTimeKind.Utc);
    TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
    Console.WriteLine(TimeZoneInfo.ConvertTimeFromUtc(dt1, tz));
    DateTime dt2 = new DateTime(2010, 4, 1, 23, 0, 0, DateTimeKind.Utc);
    Console.WriteLine(TimeZoneInfo.ConvertTimeFromUtc(dt2, tz));
    Console.ReadLine();
  }
}

Вывод:

12/31/2009 11:00:00 PM 
4/2/2010 12:00:00 AM

Вам понадобится .NET 3.5 или выше и работает на операционная система, которая сохраняет исторические изменения летнего времени (Vista, Win7 или Win2008).