This content has been marked as final. Show 9 replies
I'm seeing 2 things here:
#1: You have
<mx:DateField change="output.text=event.target.selectedDate.toString()" />
<mx:Text id="output" />
When you do the above and someone picks November 2, 2006 - they either see Nov 1, Nov 2, or Nov 3 appear in the Text field?
#2: You are getting date data from CF (eg, it is supposed to be November 2, 2006) and when it is put into a DateField, it may show up as Nov 1, Nov 2, or Nov 3?
Which one (or both) is happening?
Can you correlate a person's timezone with the value they are seeing? For instance, someone in New York sees Nov 2 but someone in Tokyo sees Nov 3?
#1.... the user picks 11/02/2006. The display shows 11/02/2006. When the data is saved to the database, it gets saved as 11/[01 - 03]/2006.
I have two users in the east coast... one saves as the day before, the other saves as the day after. I have other users in that time zone without the problem.
#2.... flex correctly shows what's in the database
To eliminate either Flex/Flash Player or the server/database, use a packet sniffer like Charles. Look at the request going to the server in all cases: make sure that the data leaving the client is correct.
Are you using RemoteObject and sending a Flash Date value? Or are you sending a String (for any data service) or a Number (eg, the time in m'secs)?
A question to ask is not what timezone they people are in, but what timezone the computer is set to?
One user who is in EST (Ohio, confirmed it's set right), running XP, IE 6, 100% of the time gets her dates set to the day before she actually chooses.
Another is in Australia (GMT +9:30), with XP and IE 7, and always gets the day before she chooses.
Another in ON, Canada is also always getting one day prior to the day she chooses.
It turns out I *can* re-create the issue by setting my timezone to anything earlier that CST (so GMT -5 or more). I'll follow up with detailed results.
Yeah, found the problem... Flash passes back a timestamp, not just a date, when using the datefield. So, I'd pass back "Tue Aug 29 :00:00:00 EDT 2006". Of course, CF thinks that you want to convert a timestamp to a date, and does the timezone conversion automatically, making it Tue Aug 28.
Guess I need to pass back a string instead.
Time zone issues are a real pain. The best I've found in my experience, has been to store timestamps in UTC in the database. This way, when a user in NYC saves a record at 3pm Eastern (UTC-5), it is recorded as 20:00 UTC. Then it can be displayed by anyone, anywhere in the world in their local time, in UTC, or even as the time local to creator (assuming you also store the UTC offset along with the timestamp).
The super-annoying thing is that I didn't want a timestamp, I wanted a date. That's why I used the datefield control.
I understand that this isn't a bug, per-se, but it's an unexpected behavior at best. :)
Just to put an extraordinarily fine-point on it (while beating the poor thing to death) - you can't have a date without a time (at least outside of the database). Nov 1 2006 is really Nov 1 2006 00:00:00.
What's "worse" is you can't have a time without a date either! Try to get 15:23:42 - you still need to set a date part, even if it is 00/00/0000.
Long go, in languages lost, you could have "date" and a "time" as separate types. Then someone wanted a "datetime" so date and time went out the window. I believe that was around midnight Jan 1970 ;-)