Last week, we spent some time adding better timezone handling to the application – specifically, the ability to view data in the data source’s timezone rather than the user’s local timezone. Our application leverages Adobe Flex for charting and data visualization, and it’s sufficient to say that Flex’s timezone support is frankly lacking. Flex supports determining the UTC offset, which is fine when displaying data in a user’s local timezone, but it’s insufficient for working with alternate timezones.

The recommended advice is to keep dates on the Flex-side strictly in UTC and leave the server to handling all date and timezone manipulation. The server returns UTC dates (epochs) shifted relative to the timezone that the data should be displayed in.

One challenge is that not all Flex controls work with UTC dates directly, meaning that there is inevitably some back and forth between local dates and UTC on the client side. Also, as we discovered, the UTC setters on a date tend to have unexpected side effects. It is generally better to create a new UTC date from a local date rather than invoke its UTC setters directly. Testing can also be tricky as bugs may only be visible at certain times of day (ie. when its tomorrow in GMT but still today locally) or the month (at month boundaries).

On last little bit of date fun with Flex, the Flex data visualization/charting package has a tendency to crash your browser when viewing data at DST rollovers. The bug was raised over a year ago and ostensibly fixed before this year’s DST rollover at the start of March, but it still hasn’t found its way into to release (at least as of this post).

With all of the time invested into support timezones, I can’t help but feel we’d be better off adopting some standard global metric time.