Does not handle valid time properly

ValueError: time data '2017-08-29T09:16:45.0631274-05:00' does not match format '%Y-%m-%dT%H:%M:%SZ'

https://github.com/rohe/pysaml2/blob/fd7a4f694b137a92f2a8b7f502d51fc21e3528c7/src/saml2/time_util.py#L19

[c00kiemon5ter]

I went through the code and it seems pysaml2 uses many different libs:

• time builtin module
• datetime builtin module
• calendar builtin module
• dateutil lib
• pytz lib

Additionally, not all time-related operations are handled through time_utils.py.

I also went through the XML Schema spec about dateTime datatype and I feel very weird reading that

The ·value space· of dateTime is closely related to the dates and times described in ISO 8601

meaning that the dateTime datatype does not represent/support the full ISO 8601 specification, and at the same time there is no clear text about the differences. I cannot understand why someone found it better to semi-specify a new format instead of taking advantage of a specification about the exact thing they wanted to specify in the first place 😞.

Regardless, I started looking for libraries with ISO 8601 support. To my surprise, there is not much support for a well-defined standard, but there are lots of libs. I looked at the python modules {time, datetime, calendar}, and libraries: pytz, arrow, moment, iso8601, isodatetime, ciso8601, numpy/datetime64, pandas/timeseries and finally aniso8601.

I think that aniso8601 stands out as the most complete implementation that is taking edge cases seriously. Additionally, it is a pure python implementation and works with the standard datetime python type. I think a refactoring should be based on that lib.

[c00kiemon5ter]

Coming back to this.

The SAML2 core specification specifies:

1.3.3 Time Values

All SAML time values have the type xs:dateTime, which is built in to the W3C XML Schema Datatypes specification [Schema2], and MUST be expressed in UTC form, with no time zone component. SAML system entities SHOULD NOT rely on time resolution finer than milliseconds. Implementations MUST NOT generate time instants that specify leap seconds.

This conflicts with the dateTime datatype specification as it disallows the timezone component and considers all dates to have been specified as UTC beforehand. The dateTime specification defines two timelines - one for timezoned dateTimes and one for untimezoned dateTimes. The SAML2 spec essentially dictates that there is only one timeline, always timezoned as UTC.

This makes things easier for the implementers, as for example, they need not consider how to compare dateTimes from different timelines (a timezoned dateTime with an untimezoned datetime.)

As such, the originally posted date 2017-08-29T09:16:45.0631274-05:00 is invalid, as it contains timezone info -05:00. The correct representation is 2017-08-29T14:16:45.063127 (converted to UTC/Z/±00:00 and timezone info removed.)

The question now becomes whether implementations actually hold that promise, and if not, how do we handle it…