Why Front-End Web Development Makes Me Sad, Issue #1092145

I have an internal reporting interface for one of my Windows Phone 7 applications that shows me more or less how much of the app is getting used every day, and I developed the reports using the eternally awesome jqPlot charting plugin for jQuery.

I generate three line plots on my main reporting page by dispatching three AJAX queries on-page, all of which are just a {Start:#date, End:#date} set of arguments. The ASP.NET MVC controller action method that receives the query then builds a time-series for me spanning that range and returns the result set over JSON, which is used to finally render the charts. Basic stuff.

My charts render beautifully in Chrome and Safari, whereas they never displayed at all in IE. I figured it was just an issue with the jqPlot plugin, despite the fact that it boasts great backwards compatibility with IE.

But then I used jqPlot in another project last week and had no issue viewing the charts in IE, so I figured something else must be up with IE and my site.

The first thing I did was analyze the responses I got back from my controller methods that were supposed to be generating the time-series, and I noticed this on IE via Fiddler:

500 Internal Server Error

The parameters dictionary contains a null entry for parameter 'start' of non-nullable type 'System.DateTime' for method 'System.Web.Mvc.JsonResult PictureViews(System.DateTime, System.DateTime)' in 'LolcatsAPI.ManagementSite.Controllers.StatsController'. An optional parameter must be a reference type, a nullable type, or be declared as an optional parameter.

So the ASP.NET MVC ModelBinder doesn’t like what I’m sending to it, but only in IE? I wonder what’s up…. Time to check in with my old friend Fiddler again, but this time I was going to see what the outbound requests looked like in both browsers.

And that’s when I saw the problem (looking at the raw outbound arguments)…



Internet Explorer 9.0


…. Internet Explorer was setting my time zone as “UTC,” which .NET’s native DateTime object does not recognize as a parsable time zone, hence why the controller was failing.

As it turns out, JavaScript’s Date.toUTCString() method behaves differently in WebKit vs. IE – the former returning a “GMT” time zone and the other a “UTC” time zone, the latter of which can’t be parsed back into a .NET DateTime. Front-end development is merciless!

Discussion, links, and tweets

I'm the CTO and co-founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET and Helios.

P.S. Get the latest from Aaronontheweb

Have my most recent essays and articles delivered directly to your mailbox.