wabatson wrote:
> One follow-up I missed is how our scenario goes.
>
> 1) Flash calls .NET Web Service.
> 2) .NET Web Service passes back a person object that contains a
> datetime (with no milliseconds).
> 3) From my understanding the person object is deserialized/decoded
> into a Flash object but does it improperly due to milliseconds missing.
> 4) The Flash code doesn't expect to do anything with the person object
> but turn around and send it back to another web service.
> 5) When it calls the second web service the Flash code serializes the
> object back to SOAP, but since it has an invalid datetime field in the
> object it spits out data with a bunch of Not A Number acronyms ( I
> believe something like NaN-NaN-Nan.....something)
>
> wabatson wrote:
> > Back in March, OrangeChicken sent the following response to a developer
> > who was having problems with DateTime in Flash. We have run into the
> > same problem. I have two questions
> >
> > 1) Is this truely a bug recognized by Adobe? I have a support call in
> > and they are slow to respond.
> > 2) In talking to another Flash/.NET developer, he felt you could
> > modify the componet to handle the date correctly. I'm guessing
> > changing the code of mx.services.PendingCall.decodeDate(), based on
> > your response below. Is this possible in your eyes.
> > 3) Also when you reference "use the datatype of date" are you refering
> > to in .NET or Flash?
> >
> > Forgive me but I'm not a Flash or .NET developer, but a PM trying to
> > follow-up on a issue for a client that is using Flash to connect to our
> > .NET product.
> >
> > OrangeChicken's response
> > ====================
> >
> > Hey CI2 - You're one of the few people to mention this bug which I find
> > weird.
> >
> > The simplest way to recreate this bug is to access a web service that
> > returns
> > at dateTime in the format "2000-01-12T12:13:14Z". Crazy that this bug
> > exists,
> > because the W3C's **example** is in that format (see
> > http://www.w3.org/TR/xmlschema-2/#isoformats). Notice there's no
> > millisecond.
> >
> >
> > The bug itself exists in mx.services.PendingCall.decodeDate() where it
> >
> > *assumes* there's milliseconds. The only way to work around it is to
> > have your
> > web service put out a *string* that's in a format Flash can handle (or
> > use the
> > datatype of 'date' instead of 'dateTime' if the time isn't important
> > for your
> > usage).
> >
> >
> > That workaround is a hassle because then you have to write parsing
> > code - bleh.