all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
@ 2020-01-29 21:00 Eric Abrahamsen
  2020-01-29 22:50 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Eric Abrahamsen @ 2020-01-29 21:00 UTC (permalink / raw)
  To: 39347


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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-29 21:00 bug#39347: 28.0.50; iso8601-parse can't handle all legal date values? Eric Abrahamsen
@ 2020-01-29 22:50 ` Lars Ingebrigtsen
  2020-01-29 23:23   ` Eric Abrahamsen
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-29 22:50 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: 39347

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-29 22:50 ` Lars Ingebrigtsen
@ 2020-01-29 23:23   ` Eric Abrahamsen
  2020-01-29 23:28     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Eric Abrahamsen @ 2020-01-29 23:23 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 39347

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-29 23:23   ` Eric Abrahamsen
@ 2020-01-29 23:28     ` Lars Ingebrigtsen
  2020-01-30  0:38       ` Eric Abrahamsen
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-29 23:28 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: 39347

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-29 23:28     ` Lars Ingebrigtsen
@ 2020-01-30  0:38       ` Eric Abrahamsen
  2020-01-30  1:03         ` Lars Ingebrigtsen
  2020-01-30  1:15         ` Lars Ingebrigtsen
  0 siblings, 2 replies; 11+ messages in thread
From: Eric Abrahamsen @ 2020-01-30  0:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 39347

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-30  0:38       ` Eric Abrahamsen
@ 2020-01-30  1:03         ` Lars Ingebrigtsen
  2020-01-30  1:11           ` Lars Ingebrigtsen
  2020-01-30  1:14           ` Eric Abrahamsen
  2020-01-30  1:15         ` Lars Ingebrigtsen
  1 sibling, 2 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-30  1:03 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: 39347

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-30  1:03         ` Lars Ingebrigtsen
@ 2020-01-30  1:11           ` Lars Ingebrigtsen
  2020-01-30  1:14           ` Eric Abrahamsen
  1 sibling, 0 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-30  1:11 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: 39347

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-30  1:03         ` Lars Ingebrigtsen
  2020-01-30  1:11           ` Lars Ingebrigtsen
@ 2020-01-30  1:14           ` Eric Abrahamsen
  1 sibling, 0 replies; 11+ messages in thread
From: Eric Abrahamsen @ 2020-01-30  1:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 39347


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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-30  0:38       ` Eric Abrahamsen
  2020-01-30  1:03         ` Lars Ingebrigtsen
@ 2020-01-30  1:15         ` Lars Ingebrigtsen
  2020-01-30  2:05           ` Lars Ingebrigtsen
  1 sibling, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-30  1:15 UTC (permalink / raw)
  To: 39347

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






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-30  1:15         ` Lars Ingebrigtsen
@ 2020-01-30  2:05           ` Lars Ingebrigtsen
  2020-01-30  3:32             ` Eric Abrahamsen
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-30  2:05 UTC (permalink / raw)
  To: 39347

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#39347: 28.0.50; iso8601-parse can't handle all legal date values?
  2020-01-30  2:05           ` Lars Ingebrigtsen
@ 2020-01-30  3:32             ` Eric Abrahamsen
  0 siblings, 0 replies; 11+ messages in thread
From: Eric Abrahamsen @ 2020-01-30  3:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 39347-done, 39347

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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-01-30  3:32 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-29 21:00 bug#39347: 28.0.50; iso8601-parse can't handle all legal date values? Eric Abrahamsen
2020-01-29 22:50 ` Lars Ingebrigtsen
2020-01-29 23:23   ` Eric Abrahamsen
2020-01-29 23:28     ` Lars Ingebrigtsen
2020-01-30  0:38       ` Eric Abrahamsen
2020-01-30  1:03         ` Lars Ingebrigtsen
2020-01-30  1:11           ` Lars Ingebrigtsen
2020-01-30  1:14           ` Eric Abrahamsen
2020-01-30  1:15         ` Lars Ingebrigtsen
2020-01-30  2:05           ` Lars Ingebrigtsen
2020-01-30  3:32             ` Eric Abrahamsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.