Comment 1 for bug 1592181

Another gnarly problem is that isotime() does two things that make it not quite iso.

First, it uses this thing called PERFECT_TIME_FORMAT which isn't.

_ISO8601_TIME_FORMAT_SUBSECOND = '%Y-%m-%dT%H:%M:%S.%f'
_ISO8601_TIME_FORMAT = '%Y-%m-%dT%H:%M:%S'
PERFECT_TIME_FORMAT = _ISO8601_TIME_FORMAT_SUBSECOND

It is NOT (as best as I can tell) to have a subsecond time with no timezone information. (see: RFC 3339, section 5.6).

date-time = full-date "T" full-time
full-time = partial-time time-offset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac]
time-offset = "Z" / time-numoffset
time-numoffset = ("+" / "-") time-hour ":" time-minute

Observe therefore that full-time has only one optional component; time-secfrac. time-offset is mandatory.

Second, isotime() uses iso8601 (the python library), which is kind-of on thin ice in some areas.

For example, see http://pyiso8601.readthedocs.io/en/latest/#where-it-differs-from-iso-8601

In the documentation for 'latest' (current: iso8601 0.1.11), I see that there are three 'listed' differences.

I see immediately above, in the 'Time Zones' section (http://pyiso8601.readthedocs.io/en/latest/#time-zones) that there are five time zones supported. Three of them are iso8601, two are not. +/-HH is the other one that is NOT iso8601.

So it happens that PERFECT_TIME_FORMAT is really not consistent with RFC 3339 and something that iso8601 (the library) does support.

These two things mean that it may well be worthwhile considering (also) submitting fixes to iso8601 (the library).