Por lo que yo sé que el operador de diferencia del tipo DateTime considera los años bisiestos: por lo¿El operador de diferencia de fecha y hora considera el horario de verano?
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?
No creo que vaya a ser así. The documentation simplemente dice que un DateTime se almacena como el número de tics desde las 12:00:00 de la medianoche del 1 de enero de 0001, pero no dice en qué TimeZone está la medianoche - tendría que asumir que si siempre fue almacenados internamente en UTC, lo dirían.
Usted puede conseguir fácilmente alrededor de esto, sin embargo: Sólo hacer:
var difference = Dt1.ToUniversalTime() - Dt2. ToUniversalTime()
y las conversiones al UTC será tener en cuenta el horario de verano
¡Pruébelo y vea!
Es tan fácil escribir una prueba como lo ha hecho para el caso de DST como lo es para el caso del año bisiesto.
El horario de verano es más específico que en las 12 zonas horarias en general y los países que las usaron.
Diferentes países o grupos de países usan fechas diferentes para cuando ocurre el horario de verano.
es un poco molesto, por no mencionar los países que no lo hacen, o partes de países.
Por ejemplo, Queensland, AU doenst tiene DST a pesar del resto del país.
No me sorprendería que no fuera así, en el caso de que lo hiciera, no podría hacerlo sin un 9 por lo menos).
Es no y que, de hecho, NO PUEDE, basada sobre el hecho de que no lo obliga a usar UTC para construir un DateTime ni le permite especificar si el horario de verano estuvo en vigencia cuando construye un DateTime con un valor de hora local. Además, permite que el modo (LT o UTC) sea "no especificado", lo cual es simplemente asqueroso.
Al permitir la construcción de valores DateTime a partir de valores de Local Time, es posible construir un valor DateTime (especificado como Local Time) ambiguo (por ejemplo, entre 1 y 2 am el 2 de noviembre en EE. UU. la hora local se repite) y no se puede convertir de manera determinista a UTC, A MENOS QUE el constructor proporcione un parámetro para especificar si el horario de verano estuvo en vigencia para la hora local dada.
Dado que no proporciona ningún parámetro de este tipo, el diseño de la clase DateTime es incompleto y defectuoso, al no tener en cuenta todos los parámetros necesarios para especificar correctamente una hora local correctamente.
Creo que esa es la razón por la que crearon la clase DateTimeOffset, que ... si se sintiera confundido por qué existe una clase aparentemente redundante ... es por eso.
Como resultado, nunca debe hacer ningún tipo de cálculo con ninguna instancia de DateTime que no esté configurada en DateTimeMode.Utc. Solo use UTC. En realidad, no puede convertir a LT o hacerlo desde LT, ya que es BUSCADO por dos bugs diferentes, en ambos sentidos. 1.Pasar de LT a UTC se rompe porque, como se mencionó, no le permite especificar si el horario de verano estuvo vigente durante esa hora ambigua en LT. Ah, también te permite especificar una hora local que es básicamente imposible, como la hora en la que saltamos cuando los relojes se adelantan. 2. Al convertir un valor UTC en el pasado a una hora local, Windows lo tacha compensando el horario de verano en función de si está en vigencia AHORA o no, en lugar del tiempo determinado, que es realmente asqueroso. 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 arreglar en algún lugar entre el lanzamiento de DOS y el último .NET Framework (~ 2 décadas)! Por supuesto, esa falla afecta los sistemas CVS y cualquier cosa que rastree los tiempos de modificación. El sistema de archivos FAT almacena las horas como locales, lo que significa que está completamente atornillado.
.NET no maneja el horario de verano correctamente, a pesar de que da las respuestas que desea. Usted quiere respuestas incorrectas.
versión corta:
¿Cómo puede saber .NET que en 1977 el horario de verano estaba en vigor todo el año, debido a la crisis de la energía?
¿Cómo puede saber .NET cuáles serán las reglas de ahorro de luz diurna en Israel, cuando la Knesset las decida año tras año?
¿Cómo sabe .NET que los EE. UU. Funcionaron en horario de verano durante la Segunda Guerra Mundial, y de 1945 a 1966 las reglas DST variaron de región a región, y las reglas todavía varían de región a región.
.NET prueba una salida de emergencia, y utiliza las reglas actuales de ahorro de luz diurna, incluso si no estaban, o serán, en efecto. El resultado es que obtienes respuestas que, si bien es lo que crees que quieres, son incorrectas.
De entrada de blog de Raymond Chen 's, Why Daylight Savings Time is nonintuitive:
¿Por qué no los (Win32) funciones de conversión de zona horaria utilizar el tiempo apropiado para la zona de la época del año?
...
Win32 no trata de adivinar qué reglas de zona horaria estaban en vigor en ese otro tiempo. Entonces Win32 dice, "Jueves, 17 de octubre, 2002 8:45:38 PST".
Nota: Pacífico Estándar Tiempo. Incluso aunque 17 de octubre fue durante Pacífico luz del día Tiempo, Win32 muestra el tiempo como tiempo estándar porque eso es lo tiempo, es ahora .
.NET dice, "Bueno, si las normas en vigor ahora también estaban en efecto en 17 de octubre de 2003, entonces eso sería tiempo de luz diurna" para que muestre "Jueves, 17 de octubre de 2003, 9:45 AM PDT "- horario de verano.
Las respuestas que obtiene son incorrectas. Pero como esperas la respuesta incorrecta, es lo que obtienes.
No, eso NO es una solución válida. Ver mi publicación. Para almacenar CORRECTAMENTE una hora local adecuada para la conversión a una hora UTC, debe especificar TODAS las compensaciones aplicadas de UTC (que incluye la zona horaria Y si el horario de verano estuvo vigente). Dado que DateTime nunca ingresa si el horario de verano estuvo activo para una hora local determinada, cada valor de tiempo local es intrínsecamente incompleto/defectuoso y, por lo tanto, no es adecuado para la conversión. Windows incluso arruina la conversión de UTC a Local, ya que parece aplicar el desplazamiento DST en función de si está en vigencia en el momento de la llamada al método en lugar de a la hora determinada, lo cual es asqueroso. – Triynko
Usted dijo "las conversiones a UTC tendrán en cuenta los ahorros de luz diurna", pero eso es imposible, porque el constructor de DateTime nunca le pregunta si el horario de verano estuvo en vigencia, por lo que no puede saber si estuvo vigente entre las horas 1 y 2 de la madrugada 2 de noviembre (en los Estados Unidos de todos modos). También tendría problemas para convertir esa hora local inexistente que DateTime le permite almacenar y omitir cuando establecemos los relojes. – Triynko
En realidad es bastante divertido. ToUniversalTime funcionará durante todo menos 2 horas en 2 días de todo el año. Mientras tanto, el ToLocalTime correspondiente (y las API subyacentes) hace que Windows muestre un tiempo de modificación de archivos incorrecto de 5 a 7 meses. fuera del año, dependiendo de si el archivo se modificó o no durante un intervalo de fechas donde su "modo" DST (activo o inactivo) coincide con el de la fecha actual. Qué error. – Triynko