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

[Jan Cholasta]

On 13.5.2014 13:24, Martin Kosek wrote:
> 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?

I don't see why any of this should be supported at the API level. If you 
need to do some preprocessing, fine, but do it on the client side.

-- 
Jan Cholasta