¿El operador de la diferencia de DateTime considera el horario de verano?

Question

Hasta donde yo sé, el operador de diferencia del tipo DateTime considera los años bisiestos: entonces

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

Pero ¿qué pasa con el horario de verano?

Answer 1

No creo que lo haga. La documentación simplemente dice que un DateTime está almacenado como el número de tics desde las 12:00:00 de la medianoche, el 1 de enero de 0001, pero no dice en qué zona horaria está realmente la medianoche, tendría que suponer que si siempre se almacena internamente en UTC, dirían así que

Sin embargo, puedes evitar esto fácilmente: solo hazlo:

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

y las conversiones a UTC tendrán en cuenta el horario de verano

Answer 2

.NET no maneja correctamente el horario de verano, a pesar de que da las respuestas que desea. quiere respuestas incorrectas.

Versión corta:

• ¿Cómo puede .NET saber que en 1977 el horario de verano estuvo vigente todo el año, debido a la crisis energética?

• ¿Cómo puede saber .NET cuáles serán las reglas del horario de verano en Israel, cuando la Knesset decida las reglas año tras año?

• ¿Cómo debe saber .NET que EE. UU. funcionó durante todo el año durante la Segunda Guerra Mundial, y de 1945 a 1966 las reglas del DST variaron de una región a otra, y las reglas aún varían de una región a otra?

.NET intenta eliminarse y usa las reglas actuales de ahorro de luz diurna, incluso si no lo fueron o no lo estarán. El resultado es que obtienes respuestas que, si bien son lo que crees que quieres, son incorrectas.

De la entrada del blog de Raymond Chen , Por qué el horario de verano no es intuitivo :

  

¿Por qué las funciones de conversión de zona horaria (win32) no utilizan la zona horaria adecuada para la época del año?

     

...

     

Win32 no intenta adivinar cuál   las reglas de zona horaria estaban vigentes en ese   otro momento. Así que Win32 dice, " jueves,   17 de octubre de 2002 8:45:38 AM PST " ;.

     

Nota: Pacífico Estándar Tiempo. Incluso   aunque el 17 de octubre fue durante el Pacífico    Hora de verano Hora, Win32 muestra la hora   como tiempo estándar porque eso es lo que   ahora es ahora .

     

.NET dice, " Bueno, si las reglas en   efecto ahora también estaban en vigor en   17 de octubre de 2003, entonces eso sería   hora de verano " por lo que se muestra   " jueves 17 de octubre de 2003, 9:45 a.m.   PDT " - hora de verano.

Así que las respuestas que obtienes son incorrectas. Pero como esperas una respuesta incorrecta, es lo que obtienes.

Answer 3

El horario de verano es más específico que las 12 zonas horarias generales y qué países las utilizan.

Los diferentes países o grupos de países usan fechas diferentes para cuando ocurre el horario de verano.

es un poco doloroso sin mencionar los países que no lo hacen, o partes de países.

Por ejemplo, Queensland, AU no tiene horario de verano que inspire al resto del país.

No me sorprendería si no lo hiciera, en caso de que lo haga, sería incapaz de hacerlo sin una información cultural, al menos).

Answer 4

No lo hará y, de hecho, NO PUEDE , ya que no te obliga a usar UTC para construir un DateTime ni te permite especificar si el horario de verano estaba vigente cuando construye un DateTime con un valor de hora local. Además, permite que el modo (LT o UTC) sea " no especificado " ;, que es solo una rutina.

Al permitir la construcción de valores de fecha y hora a partir de valores de hora local, es posible construir un valor de fecha y hora (especificado como hora local) que es ambiguo (por ejemplo, cualquier hora entre la 1 y las 2 de la madrugada del 2 de noviembre en los EE. UU., cuando el local hora se repite) y no se puede convertir determinísticamente de nuevo a UTC, A MENOS que el constructor proporcionó un parámetro para especificar si el horario de verano estaba en vigencia para la hora local dada .

Dado que no proporciona dicho parámetro, el diseño de la clase DateTime es incompleto y defectuoso, ya que no tuvo en cuenta todos los parámetros necesarios para especificar correctamente una hora local correctamente.

Creo que es por eso que crearon la clase DateTimeOffset, que ... si estaba confundido por qué existe una clase aparentemente redundante ... por eso.

Como resultado, nunca debe realizar ningún tipo de cálculo con ninguna instancia de DateTime que no esté establecida en DateTimeMode.Utc. Solo use UTC. En realidad, no puede convertir ni a LT, porque está BUSTADO por dos errores diferentes, en ambos sentidos. 1. Pasar de LT a UTC está bloqueado porque, como se mencionó, no le permite especificar si el horario de verano estaba en vigor para esa hora ambigua en LT. Oh, también te permite especificar una hora local que es básicamente imposible, como la hora que saltamos cuando los relojes están adelantados. 2. Al convertir un valor UTC en el pasado a una hora local, Windows lo complica compensando el horario de verano en función de si está vigente AHORA, en lugar de hacerlo a la hora dada, que es seriamente inoportuna. Por supuesto, es posible que haya notado este problema cuando una hora de modificación que anotó, almacenó o usó en el nombre de un archivo, un día aparece una HORA DESACTIVADA en el explorador de Windows. No, no estás loco, Windows solo tiene un error grave, ¡que nunca encontraron el momento de solucionarlo entre el lanzamiento de DOS y el último .NET framework (~ 2 décadas)! Por supuesto, ese error afecta los sistemas CVS y todo lo que rastrea los tiempos de modificación. El sistema de archivos FAT almacena las horas como horas locales, lo que significa que está completamente atornillado.

Answer 5

Pruébalo y mira!

Es tan fácil escribir una prueba como lo ha hecho para el caso de DST como lo es para el caso de año bisiesto.