Re: Trouble with xmlrpc

On Feb 16, 2007, at 4:27 PM, Alex Young wrote:

> 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.

That doesn't make any sense to me (though the spec *does* seem to say  
the same).  How am I suppose to know what time-zone to send my time  
in then?

Also, for these cases, sending a UTC time will not be any different  
than sending the user's local time.  We're still only going to be  
sending the correct time to servers in a single time-zone.

On the flip side, if the server does assume UTC time (the only sane  
choice I can think of when neither side knows the time-zone) we will  
now be sending them correct times.

To me, this change can only improve accuracy.

>> 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?

The time-zone should probably be configurable, yes, to support the  
wildly open spec.  I just think UTC is a much saner default than a  
local value the server can't possibly know.

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

I'm not super familiar the xmlrpc code, but yes, I believe it's  
reading incoming times as UTC values.  Here's the method I *believe*  
to be relevant:

     def self.dateTime(str)
       case str
       when /^(-?\d\d\d\d)-?(\d\d)-?(\d\d)T(\d\d):(\d\d):(\d\d)(?:Z| 
([+-])(\d\d):?(\d\d))?$/
         a = [$1, $2, $3, $4, $5, $6].collect{|i| i.to_i}
         if $7
           ofs = $8.to_i*3600 + $9.to_i*60
           ofs = -ofs if $7=='+'
           utc = Time.utc(a.reverse) + ofs
           a = [ utc.year, utc.month, utc.day, utc.hour, utc.min,  
utc.sec ]
         end
         XMLRPC::DateTime.new(*a)
       when /^(-?\d\d)-?(\d\d)-?(\d\d)T(\d\d):(\d\d):(\d\d)(Z|([+-]\d 
\d):(\d\d))?$/
         a = [$1, $2, $3, $4, $5, $6].collect{|i| i.to_i}
         if a[0] < 70
           a[0] += 2000
         else
           a[0] += 1900
         end
         if $7
           ofs = $8.to_i*3600 + $9.to_i*60
           ofs = -ofs if $7=='+'
           utc = Time.utc(a.reverse) + ofs
           a = [ utc.year, utc.month, utc.day, utc.hour, utc.min,  
utc.sec ]
         end
         XMLRPC::DateTime.new(*a)
       else
         raise "wrong dateTime.iso8601 format " + str
       end

That's the dateTime() module method of the Convert module in xmlrpc/ 
parse.rb.  The method begins on line 88.

So, if I'm reading that right, xmlrpc's server can't even read the  
times created by it's own client.  To me, this illustrates the  
problem perfectly.

James Edward Gray II