bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 01/30/20 02:03 AM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> Do you have a pointer to the 2000 version of the ISO8601 standard?  I
>>> could have a peek.
>>
>> These are surprisingly hard to find:
>> https://www.pvv.ntnu.no/~nsaa/8601v2000.pdf
>
> Yeah, many ISO standards cost money, so you can only find them if
> somebody has happened to have left a copy somewhere on the web "by
> accident".  :-/
>
>> Section 5.2.1.3 does the truncation stuff, including the three hyphens.
>>
>> Looking up information about 8601, the only references to this
>> "truncated representation" are from the vCard spec. That is stupid, but
>> also leads me to believe that they're still considered legal for vCards,
>> so it would be nice if they were supported. Maybe with defvar we could
>> let-bind, to say "allow these variants"? Some of the
>> potentially ambiguous stuff does seem to rely on agreement between
>> producer and consumer.
>
> Nah.  Looking at 5.2.1.3 in the 2000 version of the standard, it looks
> like what we're missing is just the e) and f) forms, and it looks like
> they're not ambiguous, so I think I'll just go ahead and add them to the
> iso8601 library.

Cool!

> I'm not sure about the a-c) variants -- the ones with implied
> century...  are they ambiguous?  Hm...  perhaps not...

I'm not worried about it for this case, at least, as vCard disallows a
through c.

>> vCard also mentions "reduced accuracy" and "expanded representation",
>> from the 2004 version of 8601 -- is that something that the library
>> currently handles? I assume it does since I haven't been able to raise
>> any other errors.
>
> The library doesn't handle "expanded representation", but it should
> handle all the "reduced accuracy" forms.  At least in the 2016 version
> of the standard.

Good enough for me. I will steal the library once you've made these
updates.

Thanks again,
Eric