Working across timezones can have its own stupid issues. I faced one of them just now.

I finished working on the initial production setup of a client ASP.NET website, and uploaded and installed it to a remote server based in United States (in the Eastern Time zone). I am based in India (with Indian Time Zone), which is 10:30 hours ahead of the server time on which the site was uploaded.

After finishing everything up, as I was validating all pages, everything seemed normal, except one page, which was not displaying properly. The page had lots of javascript used over it (ExtJs mainly), and ExtJs components were not being rendered at all.

Being completely stumped, the obvious friend (FireBug) came to the rescue. I analyzed the page, and FireBug reported that a javascript file request was responding in a 500 internal server error. Remember, the file was embedded in a .NET assembly.

I rechecked my local installation, and the same file was delivered perfectly. This confused me more. Some more investigation revealed the server was throwing this error:

Type : System.ArgumentOutOfRangeException, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
       Message : Specified argument was out of the range of valid values.
Parameter name: utcDate
       Source : System.Web
       Help link :
       ActualValue :
       ParamName : utcDate
       Data : System.Collections.ListDictionaryInternal
       TargetSite : Void UtcSetLastModified(System.DateTime)
       Stack Trace :    at System.Web.HttpCachePolicy.UtcSetLastModified(DateTime utcDate)
          at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
          at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
          at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Now what could be causing this. Here the next best friend in line (Google you know) rescued me. I immediately knew that .NET throws this error while serving files if the file modified time is ahead of the current server time.

In my case, the assembly reporting this error was modified on my system at around 6:00 p.m. And it was approx. 10:00 a.m. on the server (with same dates) while I was browsing the page. See, how timezones strike you in unexpected venues.

This issue has also been reported at Microsoft Connect:

As the above Connect page explains, you have no choice but to manually modify the modified time to be behind server date.

In my case, I better decided to wait 6 more hours before checking it again.

UPDATE: Just in case you are curious, I checked the page next day, and it was working fine.