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

[Rob Crittenden]

Dmitri Pal wrote:
> Rob, is it a big problem to do it right?

I don't consider what Pavel did to be wrong.

> It seems like we are cutting corners a bit and I understand why but my
> general experience tells me that these things are just time bombs
> waiting to explode.
> Do we really want to leave them there or we should clean it up before we
> release?
> I know it is more work but these things just do not smell right...
> Is there any argument against following XMLRPC standards?

This has nothing to do with XML-RPC. I think the name GeneralizedTime is 
a misnomer. This isn't used as a pure date string. Instead it can hold 
absolute times and periodic information. For example, here is a 
perfectly valid value:

periodic daily 1200

absolute 200912161032 ~ 200912161033

Those date values are enforced using the GeneralizedTime format but 
that's as close as things get.

> How much would it take to make the changes and who would be the right
> person to do them?

I don't think there is anything to do other than perhaps to rename the 
type (and perhaps add some additional error handling and documentation). 
We need a set of unit tests for this too.

rob

> 
> John Dennis wrote:
>> 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.
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20091105/8df57e11/attachment.bin>