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.

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.

James Edward Gray II