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

[Lars Ingebrigtsen <larsi@gnus.org>]

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.

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

> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no