[Tim]
>> Well, then since that isn't ISO 8601 format, it would be nice to have
>> a comment explaining why it's claiming to be anyway <0.5 wink>.
[Fred]
> Hmm, that's right (ISO 8601:2000, section 5.4.2). Sigh.
Ain't your fault. I didn't remember that I had seen the XML-RPC spec
before, in conj
On Thu, 10 Feb 2005 15:32:14 -0500, Fred L. Drake, Jr. <[EMAIL PROTECTED]>
wrote:
> On Thursday 10 February 2005 14:44, Tim Peters wrote:
> > Well, then since that isn't ISO 8601 format, it would be nice to have
> > a comment explaining why it's claiming to be anyway <0.5 wink>.
>
> I've posted
On Thursday 10 February 2005 14:44, Tim Peters wrote:
> Well, then since that isn't ISO 8601 format, it would be nice to have
> a comment explaining why it's claiming to be anyway <0.5 wink>.
I've posted a note on the XML-RPC list about this. There doesn't seem to be
anything that describes th
On Thursday 10 February 2005 14:44, Tim Peters wrote:
> Well, then since that isn't ISO 8601 format, it would be nice to have
> a comment explaining why it's claiming to be anyway <0.5 wink>.
Hmm, that's right (ISO 8601:2000, section 5.4.2). Sigh.
> dt.replace(microsecond=0).isoformat()
[Tim]
>> Fred, is there a reason to avoid datetime.datetime's .isoformat()
>> method here? Like so:
> Yes. The XML-RPC spec is quite vague. It claims that the dates are in ISO
> 8601 format, but doesn't say anything more about it. The example shows a
> string without hyphens (but with colons),
On Thursday 10 February 2005 14:09, Tim Peters wrote:
> Fred, is there a reason to avoid datetime.datetime's .isoformat()
> method here? Like so:
Yes. The XML-RPC spec is quite vague. It claims that the dates are in ISO
8601 format, but doesn't say anything more about it. The example shows
[EMAIL PROTECTED]
> Modified Files:
>xmlrpclib.py
> Log Message:
> accept datetime.datetime instances when marshalling;
> dateTime.iso8601 elements still unmarshal into xmlrpclib.DateTime objects
>
> Index: xmlrpclib.py
...
> +if datetime and isinstance(value, datetime.dateti
