XML validation doesn't support endOfDayFrag (24:00:00)

[simendsjo]

According to the specification, endOfDayFrag allows a dateTime to have
the timestamp 24:00:00 [1]. This is oddly enough defined as

Alternatively, endOfDayFrag combines the hourFrag, minuteFrag,
minuteFrag, and their separators to represent midnight of the day,
which is the first moment of the next day.

Which doesn't make a lot of sense as a time cannot exist in two dates at
the same time. libxml2 has support for this [2].

My first assumption of this would be that the value should be allowed,
and that it should return the implementation defined latest possible
time for a given date. My google-fu bing-fu doesn't show how others
are handling endOfDayFrag, but as the spec allows it, people are
reporting it, which breaks validation.

I notice an existing issue related ISO8601 parsing[3], which is
probably related to the parsing step.

1. https://www.w3.org/TR/xmlschema11-2/#nt-eodFrag

2. https://gitlab.gnome.org/GNOME/libxml2/commit/a1dca81df7c352cd9a14ab678750b1623f8f8ed7

3. https://github.com/dotnet/coreclr/issues/23064

[simendsjo]

Btw, here's a small testcase:

    class Program
    {
        static void Main()
        {
            var s = new XmlReaderSettings
            {
                ValidationType = ValidationType.Schema,
            };
            s.Schemas.Add("endOfDate", XmlReader.Create("c:/tmp/endOfDate.xsd"));

            var r = XmlReader.Create("c:/tmp/endOfDate.xml", s);
            var d = new XmlDocument();
            d.Load(r);
        }
    }

endOfDate.xsd:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="endOfDate">
  <xs:element name="endofdate" type="xs:dateTime"/>
</xs:schema>

endOfDate.xml:

<?xml version="1.0" encoding="utf-8"?>
<tmp xmlns:eod="endOfDate" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <eod:endofdate>2019-03-19T24:00:00</eod:endofdate>
</tmp>

[krwq]

@simendsjo I'm moving this to future because we are far in the current release cycle and this is potentially risky change and we have already shipped like that for many years. Please let me know if you are interested in sending a patch. I agree we should comply to the spec but at the same time number of affected customers is very small (this is first report I've heard about this).

[simendsjo]

I'm moving this to future because we are far in the current release
cycle and this is potentially risky change and we have already shipped like that
for many years.

Agree it might be risky. Hopefully someone with knowledge of the existing code
might find some way to reduce this, but it is a breaking change (even if just
allowing more data). As it seems quite obscure, and in little use, this fix
shouldn't affect people not using the end-of-day feature much.

Please let me know if you are interested in sending a patch.

Not sure I'm qualified as I don't know much about date/time. The issue for
validation might be solved by just fixing the DateTime, ref
https://github.com/dotnet/coreclr/issues/23064.

I agree we should comply to the spec but at the same time number of affected
customers is very small (this is first report I've heard about this).

I had no idea ISO-8601 defined 24 as a valid time until it blew up either.

[krwq]

@simendsjo I own both XML and globalization but I think everyone on our team will have to spend some time digging where to make the fix to make it least risky. I agree https://github.com/dotnet/coreclr/issues/23064 should be addressed first, very likely XML is using that code already (if not then it possibly this can be unified).

[simendsjo]

I think this bug should be kept open. Commenting to avoid closing the issue.