The timezone functionality in Flex (as of SDK 3.4.1) makes me wonder if this is the person who designed this behavior (I kid because I love). 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
Voted/annoyed.
Can Flex even deduce the “local” timezone in terms of EDT,CDT,PDT … and so forth.
hey jd – flex gets its information from the system clock however as far as I can tell there’s no way to get the timezone code. The best you can do is get the UTC offset. If you have the UTC offset you can usually deduce the timezone if you know what country the user is in.
Voted/annoyed.
Same problem here. Just voted, but the bug has been here for almost 3 years. Which evangelist can we ping to get an answer?
Hi Jason,
I’m involved with this same issue and also at an already built project. Could you give any advice on how to manage this without refactoring the hole code? Me too get into trying to override Date’s default behavior and couldn’t. I do also think on extending DateFormatters to add this functionality, but I’m wondering if there is any cleaner work around, since managing this logic at the view doesn’t seems right to me.
Thanks on advanced.
Hey Agustin, basically you have two choices:
1. keep the dates with the correct UTC time and extend all the display components to be timezone aware. depending on your app this could be a ton of work.
2. store the dates incorrectly (ie ignore timezone completely) and store the timezone in a separate field (if you need it). This really only creates an issue when data goes to/from the server so that is the main problem you then need to solve.
I decided to go with #2 because, even if you re-write all the display classes, you still have no clue what timezone you are dealing with when the data goes to the server. You know the UTC time but you have no idea what timeZone people want to see.
I wrote an adapter class that all data goes through whenever it goes to/from the server. It looks for any dates and reverses the timezone offset that is on the client. In other words, 3pm in the local timezone gets converted to 3pm UTC. (we convert everything to UTC because that is the timezone of our server)
The server saves the 3PM, however it doesn’t save timezones so it just gets saves as plain old 3PM with timezone not specified. When if need the timezone we save it as text in a separate field.
When data comes back from the server of course it is 3PM UTC which is wrong, so you just re-apply the offset to bring it back to 3PM local time.
In other words, it is always saved as 3PM everywhere.
To figure out how to convert to/from UTC, create a dummy Date object and then use date.timezoneOffset to tell you how many hours to add/subtract.
This solution, of course, it is only useful when everybody wants to see the same thing on their client, ie everybody wants to see 3PM. If people want things converted into their own time then Flex already works as-is. (i think it’s stupid though!)
Thanks for the links, it’s interesting to see there are other people with the same concerns. Gracias!
In all the conversations about dates in Flex I do not see much, if anything, about daylight savings time.
Here is a (simple?) problem:
First I have a user that is in hypothetical time zone A. This time zone has a spring forward daylight savings change on March 11/2012 @ 02:00. This means that there are only 23 hours in that day where 02:00 does not exist.
Assume the application has 24 hourly values to display for that day:
March 11th 00:00 value 0
March 11th 01:00 value 1
March 11th 02:00 value 2
…
March 11th 21:00 value 21
March 11th 22:00 value 22
March 11th 23:00 value 23
Assume also that the data above is stored in the database as UTC and some magic is applied to convert the date so that a normal hour displays correctly (e.g. May 5th 15:00 UCT in the database shows up as May 5th 15:00 in the users browser/time zone).
The question is: How do you display all 24 hours in that user’s browser? If you haven’t taken this scenario into account, what likely happens is the 24 hours are displayed but the hour/value pairs get out of step at the time change and the last hour bleeds into the next day:
March 11th 00:00 value 0
March 11th 01:00 value 1
March 11th 03:00 value 2 (notice that at this point the value is out of step with the hour)
…
March 11th 22:00 value 21
March 11th 23:00 value 22
March 12th 00:00 value 23 (the 24th hour falls on the next day)
Has anyone encountered this issue and addressed it?