Я столкнулся с тем, что может быть високосным годом в обработке NET DateTime
, в частности ToLocalTime()
. Вот код, который воспроизводит эту проблему (я в Тихоокеанском часовом поясе):Ошибка в високовом году с использованием ToUniversalTime(). AddYears(). ToLocalTime()?
DateTime dtStartLocal = DateTime.Parse("2009-02-28T23:00:00.0-08:00");
DateTime dtEndLocal = dtStartLocal.AddYears(3);
DateTime dtStartUtc = dtStartLocal.ToUniversalTime();
DateTime dtEndUtc = dtStartUtc.AddYears(3);
DateTime dtEndLocal2 = dtEndUtc.ToLocalTime();
DateTime dtStartLocal2 = dtStartUtc.ToLocalTime();
Console.WriteLine("START: 1={0}, 2={0}", dtStartLocal, dtStartLocal2);
Console.WriteLine("END : 1={0}, 2={1}", dtEndLocal, dtEndLocal2);
Console.ReadLine();
Выход есть:
START: 1 = 2/28/2009 11:00:00 PM , 2 = 2/28/2009 11:00:00 PM
END: 1 = 2/28/2012 11:00:00 PM, 2 = 2/29/2012 11:00:00 PM
Обратите внимание, что переменная, которую я сделал ToUniversalTime().AddYears(3).ToLocalTime()
, отличается от AddYears(3)
, это на один день вперед.
С кем это столкнулось? Если это ожидается, может кто-нибудь объяснить логику этого?
ПРИМЕЧАНИЕ: Да, наилучшим подходом является работа полностью в UTC, а не переключение между ними. Это не то, что влияет на меня, а на ту особенность, с которой я столкнулся. По сути, я неправильно понял, как работал AddYears()
, и теперь я вижу, почему он делает то, что он делает (см. Мой выбранный ниже ответ).
Хорошее объяснение. Это хороший пример того, почему вы должны использовать даты времени UTC для вашей арифметики дат. –
Нет, это хороший пример того, почему арифметика даты в разных часовых поясах плоха. Вы можете выполнять каждую операцию по местному времени и получать такой же результат, как если бы вы делали это в UTC. Пока вы последовательны, это не имеет значения. – Whatsit
@Whatsit: в этом случае да, но если мы добавим DST в микс, UTC - единственный разумный способ –