Оператор различия DateTime рассматривает переход на летнее время?

Переход на летнее время более специфичен, чем общие 12 часовых поясов и какие страны их использовали.

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

это немного боли, не говоря уже о странах, которые этого не делают, или о некоторых частях стран.

Например, в Квинсленде, Австралия, есть летнее время, несмотря на то, что в остальной части страны он есть.

Я не удивлюсь, если это не так. в том случае, если он это сделает, он не сможет сделать это, как минимум, из Cultureinfo 9).

Проверьте это и посмотрите!

Его так же легко написать проверьте, как вы это делали для случая ТЛЧ, как и для случая високосного года.

Не будет, и фактически НЕ МОЖЕТ , основываясь на том факте, что он не заставляет вас использовать UTC для создания DateTime и не позволяет указать, будет ли летнее время был в силе, когда вы конструировали DateTime со значением местного времени. Кроме того, он позволяет режиму (LT или UTC) быть «неуказанным», что просто бессмысленно.

Допуская создание значений DateTime из значений местного времени, можно создать значение DateTime (указанное как местное время) что неоднозначно (например, в любое время между 1 и 2 часами ночи 2 ноября в США, когда местный час повторяется) и не может быть детерминированно преобразован обратно в UTC, ЕСЛИ конструктор не предоставил параметр для определения того, было ли летнее время в влияет на заданное местное время .

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

Я думаю, поэтому они создали класс DateTimeOffset, что ... если вы были сбиты с толку, почему существует такой, казалось бы, избыточный класс ... вот почему.

В результате вам никогда не следует выполнять какие-либо вычисления с любым экземпляром DateTime, для которого не установлено значение DateTimeMode.Utc. Используйте только UTC. На самом деле вы не можете конвертировать ни в LT, ни из него, потому что он ЗАБЛОКИРОВАН двумя разными ошибками в обоих направлениях. если вы были сбиты с толку, почему существует такой, казалось бы, избыточный класс ... вот почему.

В результате вам никогда не следует выполнять какие-либо вычисления с любым экземпляром DateTime, для которого не установлено значение DateTimeMode.Utc. Используйте только UTC. На самом деле вы не можете конвертировать ни в LT, ни из него, потому что он ЗАБЛОКИРОВАН двумя разными ошибками в обоих направлениях. если вы были сбиты с толку, почему существует такой, казалось бы, избыточный класс ... вот почему.

В результате вам никогда не следует производить какие-либо вычисления с любым экземпляром DateTime, для которого не установлено значение DateTimeMode.Utc. Используйте только UTC. На самом деле вы не можете конвертировать ни в LT, ни из него, потому что он ЗАБЛОКИРОВАН двумя разными ошибками в обоих направлениях. 1. Going from LT to UTC is busted because, as mentioned, it doesn't allow you to specify whether DST was in effect for that one ambiguous hour in LT. Oh, it also allows you to specify a local hour that's basically impossible, such as the hour we skip over when the clocks are set ahead. 2. When converting a UTC value in the past to a local time, Windows screws that up by offsetting for DST based on whether it's in effect NOW, rather that the given time, which is seriously asinine. Of course, you may have noticed this problem when a modification time you wrote down, stored, or used in the name of a file, one day shows up an HOUR OFF in Windows explorer. No, you're not crazy, Windows just has a serious bug in it, which they never found the time to fix somewhere between the release of DOS and the latest .NET framework (~2 decades)! Of course, that bug affects CVS systems and anything that tracks modification times. The FAT file system stores times as local times, which means that it's just completely screwed.

.NET не обрабатывает время на дневное время правильно, даже если оно дает ответы, которые вы хотите. Вы Хотите Неправильные ответы.

Короткое версию:

• Как .NET может знать, что в 1977 году летнее время было влияло на весь год, из-за энергетического кризиса?

• Как .NET может знать, что правила сбережения дневного света будут в Израиле, когда правила определяются в год к году Кнессетом?

• Как .NET узнает, что США бегали в днд круглый год во время Второй мировой войны, а с 1945 по 1966 год правила DST варьировали регион в регион, и правила по-прежнему варьируют регион в регион.

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

Из Raymond Chen вход в блоге, Почему дневное время экономия не является неискуивным :

Почему (Win32) функции часового пояса не используют функции времени часового пояса. На время года?

...

Win32 не пытается догадаться Правила часового пояса были введены в это Другое время. Так что Win32 говорит: « Четверг, 17 октября 2002 г. 8:45:38 AM PST ».

Примечание: Pacific Время. Даже Хотя 17 октября был во время Тихого океана Дневной свет Время, Win32 отображает время как стандартное время, потому что это то, что Время это сейчас .

.NET говорит: « Ну, если правила в эффект сейчас также был влияет на 17 октября 2003 года, то это было бы летнее время «Так что он отображает "Четверг, 17 октября 2003, 9:45 утра PDT »- дневное время.

Так что ответы, которые вы получаете неверны. Но так как вы ожидаете неверный ответ, это то, что вы получаете.