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

[Dmitri Pal]

Rob Crittenden wrote:
> 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.
>

Well this makes much more sense now.
So we are passing a generalized "time rule" that contains grammar that
we defined?
Then sure it should be renamed to avoid confusion and treated as a
unicode string.



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


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


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