Re: Trouble with xmlrpc

James Edward Gray II wrote:
> On Feb 16, 2007, at 5:08 PM, James Edward Gray II wrote:
> 
>> 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:
>>>> 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.
> 
> Ah, I think I just got what you are saying Alex.
> 
> Since we pass in the Time object, it is currently configurable.  
> Converting it to UTC rules out the cases where a server provides rules 
> for us to follow, which means we have to give a way to stop the 
> conversion.  Then it is two steps instead of the current one.
> 
> I get it now and I think you are right.  Thanks for being patient with 
> me on this issue.
No worries :-)

> OK, my second point aside, is there any reason we shouldn't handle 
> DateTime as we do Time, instead of the current Date handling which drops 
> information?  I really feel we should fix that at least.
Yes please!  I was a little surprised to find that it wasn't handled 
already.

-- 
Alex