the silence is deafening on this issue.
1. flex doesn't allow the user to set the timezone, it is hard-coded to read the system setting
2. all flex date related controls (formatter, date picker, etc) are hard-code to use the non-UTC values
3. the Date class is marked final, preventing any type of work-around
4. The Date does not contain contain timezone/offset as was originally entered - it only has the relative offset based on the system timezone of the user who is currently looking at the date.
if any one of these four things was changed it would instantly allow us to deal with dates across timezones. it seems hard to believe that every one of these possible work-arounds was intentionally blocked by the flex team. is there some other solution, or is this just covering up some deficiency of the flex framework?
it's a a total buzz-kill if you have an app where people travel across timezones, or there are people in multiple timezones syncing. it's is pretty much impossible to show the correct dates easily - flex assumes you always want to display all dates in the local users's timezone.
what is the "correct" way to handle this - always store dates as two fields, one for the date, another for the timezone? then use UTC for everything..? and override all Flex date controls..? i don't get it, am i missing something?
Thanks for the reply.
I understand how to manually convert a time and basically trick the UI control to show the timezone I want. However it seems like such a hack. In this case you can't use any of the built-in Flex formatters and date UI controls. Is there no other strategy for working with timezones other than to just hack all date input and output?
I don't think it's a hack if you create a class with static public const you'll get all what you need.
I do appreciate the link, thank you - it's helpful for the conversion formula. I guess I feel that if you have to change the value of a Date object to the "wrong" value in order to work correctly with the built-in Flex date controls, in my opinion that is a bit of a hack.
You don't really see the problem until you have an app for which users enter times in a different timezone from where they are located and the data is shared. This is not really too unusual - a simple schedule app for conferences, for example. All over the world people are scheduling meetings to take place in NY (EST) The problem is not necessarily just converting the date for EST display, it's the whole strategy on how to collect the user input, store the date (in a local AIR DB, on an RPC server) and lastly, the display part. When the data moves from one machine to another, Flex keeps trying to convert to local time, so you have to "hack" it at some level.
In my app, I put the hack at the point where the server returns data to the client. I apply the offset there so the client gets, technically the "wrong" UTC time. Then I disregard the timezone in order to get the hour to display correctly. I can deal with it, it just seems way harder than necessary and it would be good to know if there is some cleaner, recommended way. From what I'm understaning, there isn't a better way?
I understand your concerns, but if you're just presenting the date, do the conversion on the server, and send the date as a string just an idea, but you have already a working solution. File a feature request and I'll vote for it.
i have it worked out for my own app but i feel dirty setting dates to the "wrong" UTC value ;-)
I think this existing bug covers the issue, if you want to vote: http://bugs.adobe.com/jira/browse/FP-175
thanks again, i do appreciate your replying.
You're welcome .