|
I searched our bugbase to see if we had
anything about the milliseconds in there but didn’t find anything. So please
file away and include a C# class or a WSDL and we’ll take a look. Get it in
now and we can try to make sure it’s fixed in 2.0 Matt From:
[email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Shirey Well, Since Flex isn't
automatically parsing the date correctly. It might be best for me to
change the type on the Web Service side to string, manually call the
.ToString() method for the date there. Send the date as a string, then
use the DateFormatter as you did and manually parse it on the Flex side.
I played around with it a bit more and I finally figured out what was going
on. Basically, if the date contains milliseconds, then Flex parses it
correctly. If not, then it fails to parse it. I tried an experiment
where I added 1 millisecond to the values I was pulling from the database, and
then all worked fine. Since adding and removing a millisecond to make
parsing work seems a little too hackish, I think I'll try the string method I
just mentioned. It's a real problem though that I hope is fixed in
2.0. All of the work I do involves C# web services. Until now I
haven't had a problem. But this is a pretty big wart. On 6/27/05, Matt
Chotin <[EMAIL PROTECTED]>
wrote: 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: [email protected]
[mailto:[email protected]]
On Behalf Of Rick Bullotta 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: [email protected]
[mailto:[email protected]]
On Behalf Of Matthew Shirey well, the WSDL says:
YAHOO!
GROUPS LINKS
-- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com YAHOO! GROUPS LINKS
|
