DateTimeParse.Parse lacks full ISO8601 support

[crozone]

DateTimeParse.Parse() (which powers DateTime.Parse() and DateTimeOffset.Parse()) currently only partially supports the ISO8601 standard. ISO8601 is heavily used in industry and having greater support for it significantly increases the usability of the DateTime.Parse methods.

Currently, the bits of ISO8601 that are supported are:

• Sortable date/time pattern ("s"). 2009-06-15T13:45:30 = ISO8601 without timezone.

• Round-trip date/time pattern. ("O"/"o"). 2009-06-15T13:45:30.0000000-07:00 = ISO 8601 with timezone offset.

Notable formats that are currently omitted:

• Dates, Times, or DateTimes without dash or colon separators: 20171201, 123031, 20090615T134530+1100

• Datetimes that have a decimal fraction added to the lowest order time element when it isn't seconds:
  2009-06-15T13:45.5 or 2009-06-15T13.5

• Week notation (with day): 2017-W48 or 2017-W48-4

• Ordinal date notation: 2017-001 - 2017-334

• Yearless date notation: --10-31, --1031.

• Times that use a comma (',') as a decimal separator for the lowest time element. ISO8601 universally allows the use of both a comma (',') or a period ('.') as a decimal separator, independent of current culture. Currently, only a period ('.') is supported, regardless of the CultureInfo.NumberFormat.NumberDecimalSeparator provided (although both should be allowed irrespective of culture).

[mburbea]

Also of note is lacking support for 24:00:00. Which is an alternative form of midnight.
E.g. 2009-06-15T24:00:00Z currently throws an exception.

[niemyjski]

+1

[BellBat]

+1

[danmoseley]

for folks doing +1 .. it would probably be helpful if you could describe your use cases.

[niemyjski]

Our use case is to support the spec and to have interop with external systems.

[danmoseley]

What sorts of systems? (Completely appreciate what you're saying, but for proposals like this, it's about pulling together supporting data.)

[niemyjski]

I handle importing data from many third-party systems as well as listening to internal systems via kafka where we handle short dates (time only). A lot of educational type systems use the prefixes as mentioned above. In other apps you can have date-based invoices. The more support for the standard the better!

[TonyValenti]

I could really use this. I interact with a lot of JSON APIs and I'm running into a lot of issues interacting with Python APIs that use proper DateTimeOffset values.

[eiriktsarpalis]

If this gets implemented, the corresponding implementations in the Utf8Parser, IParsable<T> and IUtf8SpanParsable<T> should be updated as well.