[Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter

[Petr Viktorin]

On 05/07/2014 06:15 PM, Dmitri Pal wrote:
> On 05/07/2014 11:46 AM, Nathaniel McCallum wrote:
>> On Wed, 2014-05-07 at 09:50 -0400, Dmitri Pal wrote:
>>> On 05/07/2014 04:06 AM, Jan Cholasta wrote:
>>>> On 6.5.2014 19:55, Nathaniel McCallum wrote:
>>>>> I know it is a bit late on this, but for the OTP token import
>>>>> script, I
>>>>> have to have support for the full ISO 8601. My plan right now is to
>>>>> use
>>>>> python-dateutil for this.
>>>>>
>>>>> Using dateutil would simplify some of this code. Is there a reason we
>>>>> aren't using dateutil?
>>>> IIRC it was rejected right at the beginning as an overkill.

AFAICS python-dateutil allows a lot of formats other than ISO 8601, 
including "5:50 A.M. on June 13, 1990" or even "09-25-2003". I'd rather 
stick to something well-defined, and fail hard on potentially ambiguous 
formats. I dont' see a guarantee that python-dateutil won't change the 
ad-hoc formats in the future.

>>> What are the alternatives?
>> Hand-coded date parsing, AFAICS. That is what we are currently doing. In
>> order to make this sane, we greatly restrict the date formats permitted
>> as input to a small subset of ISO 8601. This is possible because we just
>> tell the users to type the date in one of the supported formats.

One difference is that we allow using a space instead of 'T' for 
datetime values. The standard allows omitting the T by mutual agreement, 
and python-dateutil does support this.

>> Unfortunately, I can't make that trade-off in the token import script
>> since I have no control over the input. Since I have to support all of
>> ISO 8601 (including timezone conversions), the dateutils module is
>> pretty much the only option. If we adopt it for OTP import, we might as
>> well throw away our hand-coded date parsing.

I'm not a fan of the full ISO 8601 beast (sections 5.3-5.5 of RFC3339 
sum it up nicely), but it's a standard; if we can convince 
python-dateutil to only parse ISO 8601 and generalized time, let's use it.

>> Nathaniel
>>
>>
> I would leave this till next week for Martin and Petr3 to chime in.
> I do not have a problem but I am not sure I can assess all the
> implications.

-- 
Petr³