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³
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
