Confusing TimeZone Offset Functionality in Flex
- November 16th, 2009
- Posted in AIR . Announcements . Flex
- Write comment
The timezone functionality in Flex (as of SDK 3.4.1) makes me wonder if this is the person who designed this behavior. It’s clear that the functionality was designed to magically handle the difficult subject of timezone and I appreciate that. The problem is that, athough Flex goes through the trouble of calculating the UTC time automatically, you have no clean way to obtain input or display date values in anything other than the local system time. So in order to display dates in other timezones, you actually have to enter incorrect UTC values and “trick” flex into showing the value that you want. Additionally the remote server communication is very confusing and inconsistent with local (AIR) db storage. The server has no way of knowing what the real value of your Date is unless you also provide it with the local clients current timezone offset. Meanwhile, dates saved to a local DB have no timezone info stored with them at all. Saving dates locally (AIR) can be downright dangerous if the system timezone changes while the app is open, including daylight savings changes.
If this is something that has caused you grief, I encourage you to vote for the issue to be fixed in the Flex SDK.
The crux of the problem is a combination of three things. First that all Dates are timezone aware, yet they are “locked” to the local system timezone and the offset property is read-only. The second is that all of the Date formatting functions and Date-related UI controls have no concept of timezone. The third is that the Date class is marked Final, so there is no way for developers to extend the class and override the default behavior. It almost seems like it was an intentional effort to prevent any apps from displaying anything other than local time, which is weird. The unfortunate side effect of this design is that it forces developers to use very ugly hacks.
In my mind there would be two “correct” way to deal with this. The first would be to allow the timezone offset property of a Date to be writable. This would allow developers to store the correct UTC time but specify the offset of their choosing for input and display. To me this makes the most sense and I don’t understand at all why it isn’t allowed unless there is some low-level feature of the Flash engine that makes this difficult.
A less optimal solution, if changing the timezone is not possible, would be to re-write all of the Date related UI controls and functions (formatters, etc) so that they can accept input and display output in a different timezone from the local system. This would be a ton of work and you’d probably run into problems with third-party components that weren’t written the same way. This would at least allow you to keep your date values stored correctly, though.
What developers are currently forced to do instead is to actually create Dates with incorrect UTC values in order to get them to display correctly. If I have a meeting in NY at 5PM but I am physically in PST, I have to set the time to 5PM PST in order to show it on a calendar 5PM. But 5PM PST is actually 8PM EST so this is not technically correct – the UTC value is off by 3 hours. Flex of course wants this item to show up on my calendar as 2PM PST because it does not think a user would ever want to see time written in it’s relevant timezone. When I pass this to the server, of course, I have to neutralize the senders timezone offset on the way in, and then account for the receiver’s timezone on the way out.
For now I’ve managed to work-around all of these issues, however it is a constant worry for my team since our users are managing events that take place around the world, some of them traveling to a new timezone every day. I hope that Adobe will address this seemingly minor issue in a future release.
Hi,
Though I agree with you that it is a bit confusing about the Date and timeZoneOffset, I do not agree with your opinion completely. I mean there is no point in making the timeZoneOffset as a read/write property. I have worked in many projects which were global and which needed to show dates in local timezone of the user wherein the input from the DB was a UTC date. Thoughit takes a little extra effort, it is not so much difficult to convert the date from UTC to any timezone and display it accordingly. (You can directly add or remove milliseconds to the date object based on that of the offset).
I also felt earlier that the formatter could a take an additional parameter of how much offset we want to add to a date before displaying – but if you know that you have to do this then the DateFormatter class is not final, you can extend it and can have your addition param for the offset.
Hey Dexterous, thanks for the post. Well, I’ve already solved all of these issues for my own needs – unfortunately I’ve ran into just about every problem along the way due to the nature of my company’s main product. We have people in timezones all over the world who are working on schedules for touring productions. The users are across the globe and the events they are planning are constantly moving across timezones. So our sensitivity to timezone offsets is probably way more intense than the average app – I definitely recognize that.
I know Flex is trying to help by dealing with the timezone offset. Unfortunately if you don’t want that behavior then you’re stuck using either Date hacks or UI hacks. And they poured salt in the wound by making Date final. It’s seems to me they are only designing the API for a certain use case, which unfortunately doesn’t fit my needs. That’s just my humble-but-correct opinion!
Thanks for stopping by, j
I just dont understand why this cant be done right out of the box. I am getting really annoyed with this date BS!!!
Hey John, I hear you. Please vote for Adobe to do away with the final declaration on the Date class (linked above).
If I were designing my app from scratch again, I would write some sort of wrapper object that accepts Dates and then outputs them in the correct timezone.
I might even just store dates as string data and then intercept them anytime they get displayed or persisted, but I hate the thought of not using the correct data type.
Thanks for stopping by