Support 24:00 in hh:mm for ISO8601 dates

[JamesNK]

A time of 24:00 is a valid in ISO8601 dates.

Midnight is a special case and may be referred to as either "00:00" or "24:00". The notation "00:00" is used at the beginning of a calendar day and is the more frequently used. At the end of a day use "24:00". "2007-04-05T24:00" is the same instant as "2007-04-06T00:00" (see Combined date and time representations below).

https://en.wikipedia.org/wiki/ISO_8601

var dt = DateTimeOffset.Parse("2007-04-05T24:00");
var dt = DateTime.Parse("2007-04-05T24:00");

System.FormatException: 'The DateTime represented by the string '2007-04-05T24:00' is not supported in calendar 'System.Globalization.GregorianCalendar'.'
   at System.DateTimeParse.Parse(ReadOnlySpan`1 s, DateTimeFormatInfo dtfi, DateTimeStyles styles, TimeSpan& offset)
   at System.DateTimeOffset.Parse(String input)
   at ConsoleApp17.Program.Main(String[] args) in C:\Users\James\source\repos\ConsoleApp17\ConsoleApp17\Program.cs:line 10

Should be fixed in DateTimeOffset.Parse/DateTime.Parse and new Utf8Parser API.

[JeremyKuhne]

According to ISO 8601-1:2019 "5.3.2 - Beginning of the day" this is explicitly not supported:

For information interchange there is no representation of end of day. It is recognized that the expression ‘24:00:00’ is used as a natural language expression to denote end of a day; but for the benefit of clarity, ‘24’ shall not be used to represent hour in accordance with this document.

Additionally, "4.3.8 Clock hour and hours duration" is very explicit about valid hours being between 00 and 23.

ISO 8601-2:2019 "7.3.2 Beginning of the day" also calls out explicitly that "end of day" is not supported.

(I don't know if Wikipedia is accurate to some older revision of the specification. I only have access to the most current.)

cc: @layomia, @tarekgh

[tarekgh]

I agree with @JeremyKuhne too. the hours should be from 0 to 23. looking at https://tools.ietf.org/html/rfc3339#section-5.7 you can also see it is explicit saying in the section 5.7. Restrictions:

   Although ISO 8601 permits the hour to be "24", this profile of ISO
   8601 only allows values between "00" and "23" for the hour in order
   to reduce confusion.

In section 5.6. Internet Date/Time Format it mention:

time-hour       = 2DIGIT  ; 00-23

Although Appendix A. ISO 8601 Collected ABNF suggest time-hour = 2DIGIT ; 00-24 but the same appendix saying:

ISO 8601 does not specify a formal grammar for the date and time
   formats it defines.  The following is an attempt to create a formal
   grammar from ISO 8601.  This is informational only and may contain
   errors.  ISO 8601 remains the authoritative reference.

Note that due to ambiguities in ISO 8601, some interpretations had to
   be made.  First, ISO 8601 is not clear if mixtures of basic and
   extended format are permissible.  This grammar permits mixtures. ISO
   8601 is not clear on whether an hour of 24 is permissible only if
   minutes and seconds are 0.  This assumes that an hour of 24 is
   permissible in any context.  Restrictions on date-mday in section 5.7
   apply.

If the latest version of ISO8601 (year 2019) is explicit regarding that as @JeremyKuhne mentioned, then we should stick with that and not support 24 to avoid any confusion.

[atruskie]

I think the key thing here is to be able to parse user input. I've regularly needed to parse "24:00:00" and I usually have to write wrapper methods (or use NodaTime) to handle this case.

As soon as the dates are parsed, they are of course normalized to 00-23.

And as per the guidance from the spec, we shouldn't be able to format/output a date with the value 24 in the hour component.

For reference, NodaTime took a similar approach: the ability to parse 24:00:00 exists, but the internal representation of that date is just the next day. See nodatime/nodatime#198 and https://stackoverflow.com/a/20879976/224512

[JeremyKuhne]

I think the key thing here is to be able to parse user input.

I'm fine with considering parsing it, but not as part of the "O" format.

[tarekgh]

I'm fine with considering parsing it, but not as part of the "O" format.

That will be more tricky. DateTime non-exact parser has a lot heuristics to detect which part of the date/time string is year, month, day, hour, minute...etc. trying to support 24 as hour will have a lot of disadvantages here and can cause a lot of other breaks.
I would say, either allow 24 in O only or not.

[KalleOlaviNiemitalo]

https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime specifically permits 24:00:00 but does not distinguish it from 00:00:00 on the next day. https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#time is less clear on whether it allows 24:00:00.

When using WCF to access a third-party SOAP service that declares some elements as xsd:time and occasionally responds with 24:00:00, I have had to edit the imported WSDL and change the type to xsd:string, so that my application could receive the data and then parse it more tolerantly. It would have been easier, especially during WSDL updates, if .NET Framework had supported 24:00:00 on its own. However, I suppose the support could be implemented in XmlSerializer and XmlConvert, not necessarily in DateTime.Parse. That would avoid messing with the non-exact parser heuristics.

Adding DateTimeStyles.AllowEndOfDay and TimeSpanStyles.AllowEndOfDay for use with the ParseExact methods might make sense, though.

[tarekgh]

@KalleOlaviNiemitalo I think your suggestion is reasonable. maybe not even using DateTimeStyles.AllowEndOfDay can be OK even if it is a breaking change as long as we restrict the functionality to parse exact..

[KalleOlaviNiemitalo]

OTOH, supporting 24:00:00 for xsd:time in XmlSerializer would also require changing XmlSerializationWriter.FromTime, which is called by generated code. It currently writes 00:00:00 instead, and changing that could break someone's application. Perhaps the compatibility risk could be minimized by writing 24:00:00 only when value == DateTime.MinValue.AddDays(1) exactly, not when value is some other midnight. That starts looking like quite a hack, though. 🙁

This problem does not exist for xsd:dateTime.

[makersky]

Unfortunately it's no longer valid.
ISO 8601-1:2019

[KalleOlaviNiemitalo]

Although ISO 8601 no longer allows 24:00, I believe XML Schema Part 2 still allows it, and it is actually used. Thus, I would still like to have this in XmlSerializer and XmlConvert, even if not in DateTime and DateTimeOffset themselves.

[ericek111]

It's supported again! See ISO 8601-1:2019/Amd 1:2022.

[JamesNK]

As of ISO 8601-1:2019/Amd 1:2022, midnight may be referred to as "00:00:00", corresponding to the instant at the beginning of a calendar day; or "24:00:00", corresponding to the instant at the end of a calendar day.[1] ISO 8601-1:2019 as originally published removed "24:00" as a representation for the end of day although it was permitted in earlier versions of the standard.