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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to