L'operatore di differenza di DateTime considera l'ora legale?

Question

Per quanto ne so, l'operatore di differenza del tipo DateTime considera gli anni bisestili: quindi

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

Ma che dire dell'ora legale?

Answer 1

Non credo che lo farà. La documentazione dice semplicemente che un DateTime è archiviato come il numero di tick dalla 12:00:00 di mezzanotte, 1 gennaio 0001, ma non dice in quale fuso orario sia effettivamente la mezzanotte - dovrei presumere che se fosse sempre stato archiviato internamente in UTC, avrebbero detto così.

Puoi facilmente aggirare questo però: basta:

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

e le conversioni in UTC terranno conto dell'ora legale

Answer 2

.NET non gestisce correttamente l'ora legale, anche se fornisce le risposte desiderate. vuoi risposte errate.

Versione breve:

• Come può .NET sapere che nel 1977 l'ora legale era in vigore tutto l'anno, a causa della crisi energetica?

• Come può .NET sapere quali saranno le regole dell'ora legale in Israele, quando le regole verranno decise di anno in anno dalla Knesset?

• In che modo .NET può sapere che durante la Seconda Guerra Mondiale gli Stati Uniti hanno corso tutto l'anno durante l'ora legale, e dal 1945 al 1966 le regole dell'ora legale hanno variato da regione a regione, e le regole continuano a variare da regione a regione.

.NET tenta un cop-out e utilizza le attuali regole sull'ora legale, anche se non erano o saranno in vigore. Il risultato è che ottieni risposte che, sebbene siano ciò che pensi di voler, non sono corrette.

Dal post del blog di Raymond Chen , Perché l'ora legale non è intuitiva :

  

Perché le funzioni di conversione del fuso orario (win32) non usano il fuso orario appropriato per il periodo dell'anno?

     

...

     

Win32 non tenta di indovinare quale   le regole del fuso orario erano in vigore a questo   altro tempo. Quindi Win32 dice, " giovedì,   17 ottobre 2002 8:45:38 PST " ;.

     

Nota: Pacifico Standard Ora. Anche   sebbene il 17 ottobre fosse durante il Pacifico    Ora legale , Win32 visualizza l'ora   come orario standard perché è quello che   ora è ora .

     

.NET dice, " Bene, se le regole in   l'effetto ora era anche attivo   17 ottobre 2003, quindi sarebbe   ora legale " così viene visualizzato   " Giovedì 17 ottobre 2003, 9:45   PDT " - ora legale.

Quindi le risposte che ottieni sono sbagliate. Ma poiché ti aspetti una risposta sbagliata, è quello che ottieni.

Answer 3

L'ora legale è più specifica dei 12 fusi orari generali e di quali paesi li hanno utilizzati.

Diversi paesi o gruppi di paesi utilizzano date diverse per quando si verifica l'ora legale.

è un po 'un dolore davvero non menzionare i paesi che non lo fanno, o parti di paesi.

Ad esempio il Queensland, AU non ha l'ora legale per ispezionare il resto del paese.

Non sarei sorpreso se non lo facesse, nel caso in cui lo facesse non sarebbe in grado di farlo senza almeno un cultureinfo).

Answer 4

Non lo farà e in effetti NON PU , in base al fatto che non ti costringe a utilizzare UTC per costruire un DateTime né ti consente di specificare se l'ora legale era in vigore quando costruisci un DateTime con un valore di ora locale. Inoltre, consente alla modalità (LT o UTC) di essere "non specificata", che è semplicemente asinina.

Consentendo la costruzione di valori DateTime dai valori dell'ora locale, è possibile costruire un valore DateTime (specificato come ora locale) che è ambiguo (ad esempio in qualsiasi momento tra l'1 e le 2 del 2 novembre negli Stati Uniti, quando il locale l'ora si ripete) e non può essere convertito in modo deterministico in UTC, A MENO CHE il costruttore non abbia fornito un parametro per specificare se l'ora legale era interessata per l'ora locale specificata .

Poiché non fornisce tale parametro, il design della classe DateTime è incompleto e imperfetto, non avendo considerato tutti i parametri necessari per specificare correttamente l'ora locale.

Penso che sia per questo che hanno creato la classe DateTimeOffset, che ... se tu fossi confuso perché esiste una classe apparentemente così ridondante ... ecco perché.

Di conseguenza, non si dovrebbe mai fare alcun tipo di calcolo con nessuna istanza DateTime non impostata su DateTimeMode.Utc. Usa solo UTC. In realtà non è possibile convertire in o da LT, perché è BUSTATO da due diversi bug, in entrambi i modi. 1. Passare da LT a UTC è fallito perché, come detto, non consente di specificare se l'ora legale era in vigore per quell'ora ambigua in LT. Oh, ti permette anche di specificare un'ora locale che è praticamente impossibile, come l'ora che salta quando vengono impostati gli orologi. 2. Quando si converte un valore UTC in passato in un orario locale, Windows lo rovina compensando l'ora legale in base al fatto che sia in vigore ORA, piuttosto che al tempo dato, che è seriamente assente. Naturalmente, potresti aver notato questo problema quando un tempo di modifica che hai annotato, archiviato o utilizzato nel nome di un file, un giorno mostra un HOUR OFF in Windows Explorer. No, non sei pazzo, Windows ha solo un grave bug, che non ha mai trovato il tempo di riparare da qualche parte tra il rilascio di DOS e l'ultimo framework .NET (~ 2 decenni)! Ovviamente, quel bug influenza i sistemi CVS e tutto ciò che tiene traccia dei tempi di modifica. Il file system FAT memorizza i tempi come orari locali, il che significa che è completamente avvitato.

Answer 5

Provalo e vedi!

È altrettanto facile scrivere un test come hai fatto per il caso DST come per il caso dell'anno bisestile.