DateTime operador de diferença considera o horário de verão?

Question

Tanto quanto eu sei que o operador de diferença do tipo DateTime considera anos bissextos: assim

new DateTime(2008, 3, 1) - new DateTime(2008, 2, 1) // should return 29 days
new DateTime(2009, 3, 1) - new DateTime(2009, 2, 1) // should return 28 days

Mas o que sobre o horário de verão?

Answer 1

Eu não acho que vai. A documentação simplesmente diz que um DateTime é armazenado como o número de tiques desde 12:00:00 meia-noite, 1º de janeiro de 0001, mas não diz em que fuso horário da meia-noite realmente é - eu teria que assumir que se estava sempre armazenados internamente em UTC, eles diriam -lo.

Você pode facilmente obter em torno deste embora: Basta fazer:

var difference = Dt1.ToUniversalTime() - Dt2. ToUniversalTime()

e as conversões para UTC terá em conta poupança da luz do dia

Answer 2

.NET não lidar com o horário de verão corretamente, mesmo que ele dá respostas que você quer. Você deseja respostas incorretas.

Versão curta:

• Como pode .NET saber que em 1977 o horário de verão estava em vigor o ano inteiro, devido à crise energética?

• Como pode .NET saber quais são as regras de horário de verão vai estar em Israel, quando as regras são decidiu no ano-a-ano pelo Knesset?

• Como é .NET saber que os EUA correu em DST ano durante a Segunda Guerra Mundial, e 1945-1966 as regras de DST região variou para região, e as regras ainda variam de região para região.

.NET tenta um cop-out, e usa as regras de horário de verão atuais, mesmo que eles não foram, ou serão, com efeito. O resultado é que você obter respostas que, enquanto são o que você pensa que você quer, estão incorretas.

De Raymond Chen 's entrada de blog, Por que o horário de verão é nonintuitive :

Por que as funções de conversão (Win32) de fuso horário não use o fuso horário apropriado para a época do ano?

...

Win32 não tenta adivinhar qual regras de fuso horário já estavam em vigor que outra hora. Então Win32 diz: " quinta-feira, 17 de outubro, 2002 08:45:38 PST ".

Nota: Pacific Padrão Hora. Até embora 17 de outubro foi durante Pacífico Daylight Time, Win32 exibe o tempo como o tempo padrão porque é isso que tempo é agora .

.NET diz: " Bem, se as regras em efeito agora também estavam em vigor na 17 de outubro de 2003, então, que seria horário de verão ", por isso exibe "Quinta - feira, outubro 17, 2003, 09:45 PDT." - hora de Verão

Assim, as respostas que recebo são errado. Mas desde que você espera a resposta errada, é o que você ganha.

Answer 3

O horário de verão é mais específico do que os gerais 12 fusos horários e que os países usaram.

Diferentes países ou grupos de países usam datas diferentes para quando DST acontece.

é um pouco de dor para realmente não mencionar os países que não fazê-lo, ou partes de países.

Por exemplo Queensland, AU doenst têm DST apesar do resto do país faz.

Eu não ficaria surpreso se isso não acontecer, no caso em que ele faz isso seria incapaz de fazê-lo com um CultureInfo 9AT o mínimo).

Answer 4

Ele não vai e que na verdade CAN NOT , com base no fato de que ele não quer forçá-lo a usar UTC para construir um DateTime nem permite que você especifique se DST estava em vigor quando você construir um DateTime com um valor de hora local. Além disso, ele permite que o modo (LT ou UTC) para ser "não especificado", que é apenas estúpido.

Ao permitir a construção de valores DateTime de valores hora local, é possível construir um valor DateTime (especificado como hora local), que é ambígua (por exemplo qualquer momento entre 1 e 2:00 em 2 de novembro nos EUA, quando o local de hora se repete) e não pode estar de volta deterministically convertido para UTC, MENOS o construtor fornecido um parâmetro para especificar se DST estava em afetam para o dado hora local .

Uma vez que não fornece nenhum tal parâmetro, o projeto da classe DateTime é incompleto e imperfeito, tendo falhado a considerar todos os parâmetros necessários para especificar corretamente um horário local corretamente.

Eu acho que é por isso que eles criaram a classe DateTimeOffset, que ... se você estava confuso por que existe tal uma classe aparentemente redundante ... é por isso.

Como resultado, você nunca deve fazer qualquer tipo de cálculo com qualquer instância DateTime que não está definido para DateTimeMode.Utc. Só use UTC. Você realmente não pode converter para ou de LT, porque é BUSTED por dois erros diferentes, em ambos os sentidos. 1. Indo de LT a UTC é preso porque, como mencionado, ele não permite que você especifique se DST estava em vigor para que uma hora ambíguo na LT. Oh, ele também permite que você especifique um hora local, que é basicamente impossível, como a hora em que pular quando os relógios são adiantados. 2. Ao converter um valor UTC no passado para a hora local, parafusos do Windows que se por compensação de DST com base em se ele é de fato agora, melhor que o tempo dado, que é a sério asinino. Claro, você pode ter notado este problema quando um tempo de modificação anotado, armazenado ou utilizado no nome de um arquivo, uma mostra dia até um OFF HOUR no Windows Explorer. Não, você não está louco, o Windows só tem um bug sério nele, que nunca encontrou tempo para correção em algum lugar entre o lançamento do DOS e o mais recente .NET framework (~ 2 décadas)! Claro, que o bug afeta os sistemas CVS e qualquer coisa que faixas modificação vezes. O sistema de arquivos FAT armazena vezes como horas locais, o que significa que ele é apenas completamente ferrado.

Answer 5

Test-lo e ver!

A sua tão fácil de escrever um teste de como você tem feito para o caso DST como é para o caso ano bissexto.