Re: Trouble with xmlrpc

James Edward Gray II wrote:
> On Feb 16, 2007, at 12:08 PM, Alex Young wrote:
> 
>> James Edward Gray II wrote:
>>> While I am complaining about xmlrpc, we have another issue.  It's 
>>> shown in this paste:
>>> http://pastie.textmate.org/40836
>>> Would a patch be accepted to make these changes?
>>> James Edward Gray II
>> Why is it a problem that the time isn't converted to UTC?
> 
> Fair warning:  this issue is certainly debatable.
> 
> Currently we send the time without any time-zone information.  It's hard 
> to see this as useful in anyway.  There is no way to add a time-zone to 
> the iso 8601 field the spec calls for either.  So basically I view it 
> that we are sending a useless field.
> 
> Sending a UTC date, on the other hand, seems to have some chance of 
> being useful.  If the server is going to assume anything, that seems the 
> most likely choice.
Really?  I'd have expected the reverse - given the freedom in the spec, 
server implementors (especially of smaller, in-house services) are 
likely not to bother changing the timezone assumptions away from 
whatever the local timezone they're in is.

> Sadly the spec (http://www.xmlrpc.com/spec) is beyond useless when it 
> comes to addressing this issue:
> 
> "* What timezone should be assumed for the dateTime.iso8601 type? UTC? 
> localtime?
> 
> Don't assume a timezone. It should be specified by the server in its 
> documentation what assumptions it makes about timezones."
> 
> I consider it insane that such a widely used spec says anything like 
> that to begin with, 
Quite.  On the other hand, all they're doing is saying "Timezone info is 
application-level data.  Handle it yourself."  Converting the timezone 
without warning pulls it back into the protocol, when the protocol has 
explicitly rejected it.

> but (much worse) I have no idea how to properly 
> implement that.  So, instead of teaching xmlrpc how to read randomly 
> formatted documents and interpret arbitrary time-zone rules from servers 
> that don't generally provide either, I'm voting we chicken out and send 
> UTC.  ;)
How would we opt out of that when we know the server's set to GMT-5, 
say?  Pre-shift the time value in the opposite direction?  Or would we 
be able to configure the timezone in an XMLRPC::Client object such that 
it defaults to UTC?

Maybe I'm missing something here.  Does xmlrpc/server convert to and 
from UTC?  Does the xmlrpc-c server or client?

I guess what I'm looking for is some sort of precedent, because this 
sounds like a quick way to confuse a lot of people...

-- 
Alex