This content has been marked as final. Show 5 replies
Dates from RemoteObjects need to adjusted for time zone. Please search on following two keywords in the help:
java.util.Calendar -> Date
Dates are sent in the Coordinated Universal Time (UTC) time zone. Clients and servers must adjust time accordingly for time zones.
java.util.Date -> Date
Dates are sent in the UTC time zone. Clients and servers must adjust time accordingly for time zones.
A quick fix, of course, would be if you sent a formatted string instead of the Date object.
This surely is a serious fundamental fault in Flex.
It can't be the underlying java to blame because the dates returned from the database show up correctly in my ColdFusion programs. They are only wrong in Flex.
Flex seems to have been developed without any thought being given to timezone invariant date/time objects.
An example of a timezone invariant date/time object is when I say for example, 'I started work on Monday October 29 at 9am, and finished at 5pm.'
If I said this to someone in a timezone 5 hours ahead of me, it would be wrong to say: 'I started work on Monday October 29 at 2pm, and finished at 10pm.' It wouldn't matter what timezone I was in on Oct 29 or what timezone the listener was in, the fact is that the first example is always correct and the second example is always wrong.
All my date/time objects in the database are timezone invariant. It doesn't matter what timezone the server is in or what timezone the user is in.
So how can I fix it?
The user could have picked up a server in any timezone. The user could be in any timezone.
Many of my RemoteObject calls return large complex objects which may or may not include date objects. Do I really have to pick them apart, find the dates, find this server's timezone and user's timezone, or as you say get them in the SQL and convert them to strings, then find them and convert them back to dates in Flex, in order to reverse the incorrect operation that Flex makes? The structure of each returned object is probably different, so I will have to write a different routine for every single RemoteObject call that might return with a date.
If alternatively I save the date as UTC, how can the client work out what timezone it was saved in to convert it back to the correct time?
Surely there is some other solution than these.
What is Adobe's view?
This is actually bad choice!
Do you mean Flex is a bad choice if you're in the airline industry, or are a railway operator, bus company, hotel, theatre, cinema etc., who all need timezone invariant date/times.
I'm now hoping the website I used to book tickets to go and see Lord of the Rings at a theatre in London wasn't developed with Flex or I'll be arriving for the performance 8 hours too late.
There must be a solution to this, but what is it??
I'm sorry if I wasn't clear in my previous message. I actually concurred with your remarks on why Flex should handle timezone invariant timestamps.
Now that I think about it, it makes more sense that there should be a way to override this 'bad default'
What? I'm clueless. Maybe some from Adobe can shed some light on it.