What we have to do is actually have the client provide it’s offset along with every request and the server then makes the adjustment to all date values going in and out.

Add to the list of other issues is that, at least on our server, a negative timezone offset (London for example) will get converted into an uint instead of a negative number. You have to convert it from uint to int which is yet another annoyance. A clue that this is happening is when people from London start seeing dates in the early 1900′s!

It would be nice to see some improvement in this area in Flex 4.

But Flex unlike Java is still a bit raw and needs some maturing.

Overall the Flash player needs to be enhanced in this area. There needs to be built in i18N libraries as well as the ability to force the client timezone or turn off the offsets.

Once it comes in, we loop over the results and just set them into Date objects within an array collection:

for (var k:int = 0; k < DataFromServer.length; k++) {

//convert from string to date

DataFromServer[k].dateTimeVariable= new Date(DataFromServer[k].dateTimeVariable);

}

This works and on 5000+ records seems to not notice much of a performance hit. Im sure if you had 40k you might have a problem. But for us this allows us to keep date/time objects in Flex without having to worry about the Flash engine compensating for time zones and DST!

Hope this helps someone.

And with everyone saying to use UTC – I don’t see the immediate benefit since I’ll have to loop through and edit any data I get from the server anyway.

If you find a good, easy solution to this, let me know. For now, I’m converting everything over to strings (lucky for me I own the server side as well). Seems like a hack to me.

Thanks

Instead of looping through your data, there is a great post from farata systems, that you might want to consider.
http://flexblog.faratasystems.com/?p=289
Hope this helps.

-Joss.

unfortunately the date in the db is stored as an sql “smalldatetime” and thats how it comes back, not as UTC, i’ve been told there are built in ms sql functions to do conversions, but have not tried it out…

so the problem here is really that we’re not storing the dates correctly in the db, but the thing is, almost every application i’ve worked on just uses date/time in sql… because it’s a great solution and covers most issues as far as needing to filter on dates and things like that.

it is just wierd that flash does that out of the box… i would have thought for it to be the other way around… as in, in order to use the timezone of the local machine it would be a player setting in the html wrapper that you specify…

anyway… thanks for the comment.

I am not entirely clear on the issue here. First of all, if you are getting a UTC date from your server, then the data will be correct, assuming it is getting treated as such and not manually parsed into a Date object. If it is UTC, then you would expect to see different times for people in different time zones.

It sounds like what you really want is that the dates being viewed by the client be displayed as if they come from a specific time zone regardless of the client machine’s operating system time zone setting. I actually ran into this issue with one of my applications. User’s of this application could change their time zone within the application, regardless of what the machine was set to. This works fine on the server side, because we were working with UTC dates and stored a time zone preference which could then be used to display the correct date to the user based on their time zone. When we added our flex app into the mix, it became a problem, though, because if we passed the utc date to the flex app, there was no way to format it based on the user’s time zone, but instead the machine time zone setting. So I came up with a couple of solutions to this problem, none of which is particularly elegant, but I can live with it because I believe they are working around a fundamental flaw in the flash player (ie not being able to configure your time zone from within the vm).

The first solution is to transform your date/time value into it’s string components, and then parse it into a date object on the client. The server determines the time zone used to get the “display” date (as opposed to utc date), and you send the month, date, year, hour, min, sec, etc fields to the client and it gets re-assembled.

The second solution is to find the time zone offset of the client and adjust values based on that. You do this by having your client send a specific known date to the server in UTC. You create a date using the , say 01-01-2000 00:00:00:0, using the year,month,date,hour,minute,second,millisecond constructor of the Date object, and then send the UTC value of that date object to the server. The server does the same thing, but using the specific time zone that you are ‘targetting’. Then you get the utc value of this date, and find the difference between it and what the client sent you. This will give you the time zone offset of the client, which you can send back to the client. Then just roll each date that the server sends to the client by this amount.

This still requires that you touch the data somewhere along the line, either on the server or the client, but there is just no way around it if you want the dates displayed using a time zone other than what the user’s machine is set to.