[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
From: |
Eric Abrahamsen |
Subject: |
bug#39347: 28.0.50; iso8601-parse can't handle all legal date values? |
Date: |
Wed, 29 Jan 2020 17:14:35 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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