JavaScript Date and ADO.NET Data Services

In my last post, we established that JavaScript Date objects are ‘local time-zone aware’, and care needs to be taken in how they are constructed and displayed. There are constructors, ‘toString’-type methods and getters/setters for both local-timezone-based and UTC-based values.

So how does this interact with ADO.NET Data Services? If you examine the payloads, you’ll see that we include a value that represents the offsets in milliseconds from UTC 1/1/1970, so values won’t be interpreted differently by browsers running in different time zones. This means, however, that if you do a simple toString on the values, you’ll get a timezone adjusted value (because toUTCString is the method that returns the UTC values). Likewise, if you’re formatting the Date from the date parts, you’ll want to use the UTC-based getters rather than the unqualified getters.

Of course, this is only for the scenarios where you want everyone to see the same values, for example if you are storing birthdays in your service. If you’re storing the scheduled time for a conference call, on the other hand, you’ll probably want the values to adjust to the browser’s time zone for display. ADO.NET Data Services will still use UTC on the wire, which is safe to pass around browsers anywhere, but you can use the local timezone-based part of the Date API to get the local-adjusted effect.

Oh, and if you haven’t already, take a look at the ASP.NET Extensions library over at – they make accessing services much simpler. Note that the API considerations outlined above still apply, because they depend on how the information is meant to be used/displayed.


Comments (0)

Skip to main content