Dale, I'm still confused about where this conversion is taking place. You say:
Granite DS goes through all the serialization when it comes out it is converting to the clients TZ and making the date 2/4/1985. Are you looking at what is actually being passed via AMF, with a tool like Charles or ServiceCapture, and seeing that the date is coming over the wire as 2/4/1985? To me, that's the first step: knowing what's actually being sent from Granite (which I know nothing about). I don't know how or why Granite would know anything about the client time zone, but you may have some additional routine going on that we don't know about. If that's the case, then you'd have to look at the Granite routines: how it knows the client time zone, how it uses it. Similarly, if you see an odd value such as Cameron mentions, with a 24:00:00 for the time value, and the date is not manipulated in any way in Flex other than simply being converted to an AS Date, then you probably need to find a way to force the value to be correctly formatted on the server. If, however, the date is being correctly sent to Flex as 2/5/1985 00:00:00, the question is then "why is Flex changing it?" Maybe I'm missing the point entirely here; but there's nothing inherent in Flex that converts date and time to the client time zone. Sure, if you create a new Date(), it'll reflect the client computer's time. But it doesn't arbitrarily change a date it's handed from the server. So: what do you see coming over the wire in the AMF data? And if what you see there is the correct 2/5/1985 date, then could we see the relevant code around where that date is used in the Flex app? I have DOBs set all the time into SQL Server, set from both an HTML app and a corresponding Flex app. When they're read back out, they stay the same, regardless of the time on the user's computer. -- Thanks, Tom Tom McNeer MediumCool http://www.mediumcool.com 1735 Johnson Road NE Atlanta, GA 30306 404.589.0560
