|
Yes, please try to play around with this
and if you figure out what’s up file a bug report (http://www.macromedia.com/go/wish).
If you can supply a WSDL that’s even better because we can then try to verify
that it will be fixed in 2.0. Matt From: If you don’t need HH:MM:SS
resolution, try this for a test: Generate your WSDL, and save it to a
file. Tweak the WSDL to use xsd:date instead of xsd:dateTime, point your
Flex app to the modified WSDL, and see if that addresses the issue. There
are lots of posts I found on Google regarding .NET’s dateTime
serialization woes…and it seems to, by default, serialize in varying
formats depending on resolution and time zone. To be fair, the formats it
is generating should be properly parsed/processed on the Flex side based on the
following: Also, I experimented a bit with the
DateFormatter object’s parseDateString method and it worked properly on
all of the formats you generated
<mx:Script>
<![CDATA[
function
parseDateString(str:String):Date
{
return
DateFormatter.parseDateString(str);
}
function
doTest() {
alert(dateFmt.format(parseDateString("2005-06-01T00:00:00")));
alert(dateFmt.format(parseDateString("2005-06-27T18:40:41.390625-07:00")));
alert(dateFmt.format(parseDateString("2005-05-31T17:00:00-07:00")));
}
]]>
</mx:Script>
<mx:DateFormatter
id="dateFmt" formatString="{'M/D/Y' + newline +
'JJ:NN:SS'}" /> Seems like there’s a disconnect
somewhere inside of the deserialization in Flex, but I can’t be certain.
Sounds like it is worth creating a bug report. - Rick From: well, the WSDL says:
-- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com ---- LSpots keywords ?> ---- HM ADS ?> YAHOO! GROUPS LINKS
|
- RE: [flexcoders] Flex, C# Web Services, and Dates Matt Chotin
- Re: [flexcoders] Flex, C# Web Services, and Dates Matthew Shirey
- RE: [flexcoders] Flex, C# Web Services, and Dates Matt Chotin

