[Freeipa-devel] GeneralizedTime v.s datetime.datetime in XMLRPC

[John Dennis]

On 11/04/2009 03:52 PM, Rob Crittenden wrote:
> John Dennis wrote:
>> In parameters.py we define a GeneralizedTime object to be used as an
>> XMLRPC parameter. Why?
>
> GeneralizedTime isn't defined as an XML-RPC paramter, just an IPA one
> and XML-RPC just comes along for the ride. We only needed support for
> RFC 4517.

Exactly, that's the problem. GeneralizedTime is not known to anybody who 
speaks XMLRPC, but iso8601 is known to anybody who does speak XMLRPC, 
and since GeneralizedTime is a subset of iso8601 anybody requiring 
GeneralizeTime can convert to GeneralizedTime from iso8601. Whenever 
possible we should stay within the definitions of the specifications, 
since XMLRPC already has a type for iso8601 there is no need to 
introduce a private type into XMLRPC which would be known only to select 
parties.

>
>> * XMLRPC defines the dateTime.iso8601 parameter value type for passing
>> date/time information
>>
>> * Python has good support for date/time processing in it's datetime
>> module
>>
>> * Python's xmlrpclib supports both xmlrpclib.DateTime and
>> datetime.datetime objects.
>>
>> * Python's xmlrpclib can be configured to use datetime.datetime
>> objects intead of xmlrpclib.DateTime objects if you pass
>> use_datetime=True when invoking xmlrpclib.loads(), however we don't do
>> that. Why?
>
> Never needed dates.

This has nothing to do with needing dates, rather it's an issue of which 
date/time object xmlrpclib will use. xmlrpclib apparently was written 
prior to the introduction of datetime.datetime so it created its own 
date/time type called DateTime. The introduction of datetime.datetime 
should supersede xmlrpclib.DateTime but it was left as the default for 
backwards compatibility. We have no need for that backward 
compatibility, we should be representing date/time information in 
Python's native datetime.datetime object.

>
>> * ISO 8601 is an internet standard for passing date time information
>> between cooperating network entities. However GeneralizedTime is only
>> valid in a subset of binary protocols (primarily LDAP and PKI)
>
> And it is LDAP we end up speaking.

No, our API is not speaking native LDAP, we're providing an abstraction 
layer over LDAP.

>
>> Given that ISO 8601 is the preferred standard, that's it is directly
>> supported by XMLRPC, is compatible with datetime.datetime and the fact
>> datetime.datetime has excellent support in Python shouldn't we be
>> using datetime.datetime for all our date/time information and only
>> convert to and from GeneralizedTime for the subset of interfaces which
>> require GeneralizedTime?
>>
>
> This could always be revisited but at the time we didn't need full-blown
> support and in fact don't want timezone information.

datetime.datetime can be use with and without timezone information. We 
probably want to establish a convention that all date/time information 
is exchanged in UTC (effectively the same thing as omitting timezone 
information, if that's what you meant). datetime.datetime handles UTC 
trivially.

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/