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

[Martin Kosek]

On 05/13/2014 12:54 PM, Petr Viktorin wrote:
> 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.

Let me drop one heretic idea - what about having 2 parameters?

GeneralDateTime with the general parsing (via dateutil) for OTP specific use
case and then SimplifiedDateTime parameter for plugins that needs just basic
date time? I.e. with manual parsing that Tomas already implemented and that was
acked on our devel meeting?

Martin