This content has been marked as final. Show 2 replies
I also have now noticed that when sending a date back to the web service it does exactly the opposit. Flex automatically adjusts the date in the other direction so it is UTC time that goes to the server. Again for storing date/time values that are not timestamps (like client birthdates) this is a big problem.
If anyone knows how to turn this off or to set the "assumed" server time zone of the webservice please let me know.
Kelly, I replied to your flexcoders post with the following:
The problem is that .NET returns the dateTime without timezone information, i.e. the value "1977-06-12T00:00:00" is missing the suffix for timezone data. If it returned "1977-06-12T00:00:00Z" or some other timezone info it would work fine. In XSD the absence of a timezone means the date/time is technically indeterminate by a significant range (+/- 14 hours for various DST worst cases I presume). Flex 2.0 interprets an XSD dateTime as an ActionScript Date in all cases - but without any timezone information it currently uses UTC to construct the date. We have a bug that asks us to consider a change to this behavior to assume the local client timezone when creating the date, but both of these solutions are technically arbitrary.
Irrespective of Flex, ActionScript Dates are always displayed in the local timezone no matter what... there are various UTC helper methods to get information back in the UTC timezone.
Your manual correction probably isn't working because you would have to take into account that the timezone-less dateTime has been interpreted in the UTC timezone but then on the default display of the Date it's in your local timezone. If you can't get .NET to include timezone information then for now I suggest sending a String back instead to avoid this complication.