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

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

[Eric Abrahamsen]

Hi!

I'm writing a small library for parsing vcards, and would like to use
the new iso8601 library, when available, for parsing date properties.

I'm testing out `iso9601-parse' with the example values from the vcard
RFC, and am getting errors from the example date value "---12", from
https://tools.ietf.org/html/rfc6350#section-4.3.1.

My understanding is that "---12" as a date should parse to:

(nil nil nil 12 nil nil nil -1 nil)

Ie, "the twelfth" (though the twelfth of what, we don't know). "----12"
also raises an error. The value "--0412" parses correctly to "April
twelfth".

Is this a bug that can be fixed, or a date value that isn't supported?

Thanks,
Eric

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I'm testing out `iso9601-parse' with the example values from the vcard
> RFC, and am getting errors from the example date value "---12", from
> https://tools.ietf.org/html/rfc6350#section-4.3.1.
>
> My understanding is that "---12" as a date should parse to:
>
> (nil nil nil 12 nil nil nil -1 nil)

I'm unable to find that form in

http://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf

The RFC talks about the ISO8601 standard from 2000 -- perhaps those
forms have been deprecated?

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

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

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I'm testing out `iso9601-parse' with the example values from the vcard
>> RFC, and am getting errors from the example date value "---12", from
>> https://tools.ietf.org/html/rfc6350#section-4.3.1.
>>
>> My understanding is that "---12" as a date should parse to:
>>
>> (nil nil nil 12 nil nil nil -1 nil)
>
> I'm unable to find that form in
>
> http://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf
>
> The RFC talks about the ISO8601 standard from 2000 -- perhaps those
> forms have been deprecated?

I sure hope so! Anyway, looks like the library is correct, and I just
get to decide if I want to support deprecated forms that might be sent
by someone's random outdated carddav server. Bleagh.

I want this package to support older Emacs than 27 -- I wonder if anyone
would yell at me if stuck a copy of iso8601.el in the package, and only
load it if the built-in one can't be found.

Eric

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I sure hope so! Anyway, looks like the library is correct, and I just
> get to decide if I want to support deprecated forms that might be sent
> by someone's random outdated carddav server. Bleagh.

I think we could extend the library to handle those forms -- if they
aren't ambiguous.  (I seem to vaguely remember that there were some
forms that were ambiguous when shortened, but I don't remember the
details.)

Do you have a pointer to the 2000 version of the ISO8601 standard?  I
could have a peek.

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

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

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I sure hope so! Anyway, looks like the library is correct, and I just
>> get to decide if I want to support deprecated forms that might be sent
>> by someone's random outdated carddav server. Bleagh.
>
> I think we could extend the library to handle those forms -- if they
> aren't ambiguous.  (I seem to vaguely remember that there were some
> forms that were ambiguous when shortened, but I don't remember the
> details.)
>
> 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

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.

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.

Thanks for looking in to this,
Eric

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

[Lars Ingebrigtsen]

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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've now done so on the trunk.

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

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

[Eric Abrahamsen]

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

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

[Lars Ingebrigtsen]

Hm...  I didn't add support for "---12T14" (that is, 14:00 on the
twelfth)...  I didn't peruse the 2000 version of the standard
sufficiently to see whether that was supposed to be valid or not.  My
guess is that it was.  :-/

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  I didn't add support for "---12T14" (that is, 14:00 on the
> twelfth)...  I didn't peruse the 2000 version of the standard
> sufficiently to see whether that was supposed to be valid or not.  My
> guess is that it was.  :-/

OK, I couldn't live with that, so I've now made this work:

(iso8601-parse "---12T14")
=> (0 0 14 12 nil nil nil -1 nil)

This'll be useful for exactly nobody.  :-)

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

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

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Hm...  I didn't add support for "---12T14" (that is, 14:00 on the
>> twelfth)...  I didn't peruse the 2000 version of the standard
>> sufficiently to see whether that was supposed to be valid or not.  My
>> guess is that it was.  :-/
>
> OK, I couldn't live with that, so I've now made this work:
>
> (iso8601-parse "---12T14")
> => (0 0 14 12 nil nil nil -1 nil)
>
> This'll be useful for exactly nobody.  :-)

I already count as one!

Closing the bug report now -- thanks.