DateTime.Now está lanzando una excepción

Question

Recibo una excepción en DateTime.Now en nuestro servidor que ejecuta algunos sitios web. Esto me ha sucedido dos veces en los últimos 3 días. Muy extraño. Me pregunto si esto ha comenzado a suceder con la última actualización de Windows y si alguno de ustedes han visto un comportamiento similar que entra

La excepción lanzada es:.

BASE EXCEPTION: 
    TYPE: System.ArgumentOutOfRangeException 
    MESSAGE: Value to add was out of range. 
Parameter name: value 
    STACK TRACE: 
    at System.DateTime.Add(Double value, Int32 scale) 
    at System.TimeZoneInfo.TransitionTimeToDateTime(Int32 year, TransitionTime transitionTime) 
    at System.TimeZoneInfo.GetDaylightTime(Int32 year, AdjustmentRule rule) 
    at System.TimeZoneInfo.GetIsDaylightSavingsFromUtc(DateTime time, Int32 Year, TimeSpan utc, AdjustmentRule rule, Boolean& isAmbiguousLocalDst) 
    at System.TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc(DateTime time, Boolean& isAmbiguousLocalDst) 
    at System.DateTime.get_Now() 
    at (my code).FrontEnd.FrontEndPage.Page_Load(Object sender, EventArgs e) in (my code file)\code\presentation\FrontEndPage.cs:line 118 
    at (my code).purchase.Page_Load(Object sender, EventArgs e) in (my code file)\purchase.aspx.cs:line 94 
    at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) 
    at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) 
    at System.Web.UI.Control.OnLoad(EventArgs e) 
    at System.Web.UI.Control.LoadRecursive() 
    at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 

El código donde esto sucede es la primera línea en la sentencia if-:

HttpCookie loggedIn = Request.Cookies[Config.Instance.LoggedInCookieName]; 
if (loggedIn != null) 
{ 
    loggedIn.Expires = DateTime.Now.AddHours(4); 
    Response.Cookies.Add(loggedIn); 
} 

aunque hay una AddHours allí y en la excepción está hablando de DateTime.Add, no creo que tenga nada que ver con los AddHours, sino que es causada por la llama a Now como puedes ver en el seguimiento de la pila.

El servidor en el que estoy está ejecutando Windows Server 2003 y está ejecutando la configuración regional en inglés (Reino Unido).

Gracias por cualquier ayuda.

Answer 1

Esto podría deberse a que DateTime.Now no es seguro para la ejecución de hilos (lo cual creo que sería un error). He escuchado de algunas versiones de .net teniendo ese error. No necesariamente ayudaría a ajustar su línea de código en un bloqueo, porque todas las llamadas a DateTime.Now tendrían que ser tratadas de manera similar. Como solución alternativa, recomendaría hacer lo que hizo la persona en la pregunta similar: atrapar la excepción lanzada por DateTime.Now e intentarlo una segunda vez.

¿Puedes escribir una pequeña aplicación de prueba que llame a DateTime.Now muchas veces en varios hilos para forzarlo y verificar si esa es la causa?

¿Qué versión de .Net está utilizando los sitios web en cuestión?

Answer 2

Al revisar el código en Reflector, su excepción se produce cuando a AddDays se le dan datos erróneos en TransitionTimeToDateTime.

ambas apariciones de AddDays proceso transitionTime.DayOfWeek donde transitionTime es rule.DaylightTransitionStart o rule.DaylightTransitionEnd de GetDaylightTime (así como time.DayOfWeek, pero esto es siempre Mod 7).

Esto parece significar GetTimeZoneInformation ocasionalmente devuelve datos incorrectos donde se genera AdjustmentRule en GetOneYearLocalFromUtc que llama a GetCurrentOneYearLocal.

Como ocurre con poca frecuencia, no creo que sea debido a un registro corrupto (esperaría que ocurriera todo el tiempo), pero para ayudar a verificar más a fondo la documentación de MSDN para TIME_ZONE_INFORMATION, se describen las entradas del registro verificar.

_{Nota esta información no se almacena en caché y se recupera cada vez que llame DateTime.Now, (que por supuesto es lo correcto para hacer lo que el horario de verano podría haber acaba de cambiar, o el usuario podría haber cambiado la zona horaria actual) una una buena excusa para una optimización prematura utilizando DateTime.UtcNow tanto como sea posible y aplicando .ToLocalTime solo cuando necesite mostrar la hora al usuario.}