De acuerdo con varias publicaciones , Microsoft habilitó la capacidad de usar una configuración de aplicación, WEBSITE_TIME_ZONE , para controlar la zona horaria del servidor web.
Para probar esto, configuré este valor en "Hora estándar del este", que es mi zona horaria local.
En una página de ASP.NET MVC Razor, agregué el siguiente código:
DateTime.Now: @DateTime.Now DateTimeOffset.Now: @DateTimeOffset.Now DateTime.UtcNow: @DateTimeOffset.UtcNowcuando ejecuté esto anoche a las 5:10:07 p. m., hora estándar del este, dio el siguiente resultado:
DateTime.Now: 6/18/2015 5:10:07 PM DateTimeOffset.Now: 6/18/2015 5:10:07 PM +00:00 DateTime.UtcNow: 6/18/2015 9:10:07 PM Como puede ver, la configuración permitió correctamente que DateTime.Now devolviera el valor correcto en mi zona horaria en lugar de UTC, como suelen hacer los sitios web/aplicaciones web de Azure. DateTime.UtcNow siempre ha devuelto el valor correcto por razones obvias.
Sin embargo, DateTimeOffset.Now devuelve la hora local, pero con un desplazamiento de +00:00 , casi como si se cambiara el reloj en lugar de la zona horaria. Esto ocurre a pesar de que la documentación dice (énfasis mío):
Obtiene un objeto DateTimeOffset que se establece en la fecha y la hora actuales en el equipo actual, con el desplazamiento establecido en el desplazamiento de la hora local desde la hora universal coordinada (UTC) .
Entonces, ¿qué sucede con la configuración de WEBSITE_TIME_ZONE que afecta a DateTime.Now pero no a DateTimeOffset.Now ? ¿Y hay alguna manera de evitar eso?
Como punto de aclaración, realmente no quiero cambiar la zona horaria en el servidor. Estamos trabajando en una solución adecuada independiente de la zona horaria. Pero todavía tengo curiosidad por qué esto sucede de la manera que lo hace.
Bueno, para mí funciona ahora mismo. Si no funciona, asegúrese de establecer el valor correcto
Así que agregué a la configuración de la aplicación en la aplicación azul "WEBSITE_TIME_ZONE: E. Europe Standard Time" y funciona.
Para aquellos que tropiezan con esta pregunta. Esto está arreglado desde hace mucho tiempo.
Me estoy enfrentando al mismo problema. Desafortunadamente para mí, heredé una gran cantidad de código heredado que se escribió específicamente para la hora estándar del este, por lo que actualizarlo para que funcione con UTC no es una opción.
Después de profundizar en el código CLR, parece deberse al hecho de que la zona horaria local se compara con el registro del sistema. No veo cómo pueden admitir esto correctamente sin un cambio en el código CLR, ya que las aplicaciones web de Azure se ejecutan en máquinas virtuales compartidas.
Por el momento, solucionaré esto con el siguiente truco de reflexión al inicio del sitio para engañar a .Net para que piense que está en el horario estándar del este. No es una gran solución, y lo más probable es que se rompa si cambian la implementación de la clase TimeZoneInfo, pero es de esperar que la razón por la que la cambien sea para solucionar este problema.
// rewrite local timezone var tz = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time"); var fInfo = typeof(TimeZoneInfo).GetField("s_cachedData", BindingFlags.Static|BindingFlags.NonPublic); var cachedData = fInfo.GetValue(null); fInfo = cachedData.GetType().GetField("m_localTimeZone", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public); fInfo.SetValue(cachedData, tz);