[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
From: |
Bob Rogers |
Subject: |
bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates |
Date: |
Fri, 24 Dec 2021 10:58:53 -0500 |
From: Lars Ingebrigtsen <larsi@gnus.org>
Date: Fri, 24 Dec 2021 10:29:29 +0100
Bob Rogers <rogers-emacs@rgrjr.homedns.org> writes:
> Which (additional) formats would you like? I'm assuming we need iso8601
> and rfc822 for compatibility (in which case rfc2822 will be easy to
> provide in addition), and us-date and euro-date to disambiguate the
> month/day order. Would the third format correspond to ISO 2001-01-03?
> Do we want to support that?
Probably not -- you mostly see that in Sweden.
OK (<phew> ;-}).
> +(defun parse-date (time-string &optional format)
I think it'd be better if this was a cl-defmethod with an eql
specifier for the format.
OK, good; cl-case was easier to start, but I was also beginning to think
in terms of cl-defmethod.
> + iso8601 => parse the string according to the ISO-8601
> +standard. See `parse-iso8601-time-string'.
> +
> + iso-8601 => synonym for iso8601.
And synonyms aren't necessary -- they just confuse people reading the
code.
OK. I added the synonym because RFCs are always spelled without the
hyphen, but I wasn't sure about the convention for ISO standards. And
it seems that there isn't a well defined precedent in the Emacs sources;
C programmers mostly avoid the hyphen, but Elisp programmers are more
evenly split:
rogers@orion> find . -name '*.el' | xargs cat | tr A-Z a-z | grep -c
'iso-[0-9]'
702
rogers@orion> find . -name '*.el' | xargs cat | tr A-Z a-z | grep -c
'iso[0-9]'
798
rogers@orion> find . -name '*.[ch]' | xargs cat | tr A-Z a-z | grep -c
'iso-[0-9]'
47
rogers@orion> find . -name '*.[ch]' | xargs cat | tr A-Z a-z | grep -c
'iso[0-9]'
148
rogers@orion>
So which do you prefer?
I'm also looking at defining a date-parse-error condition with a few
error symbol "subclasses," but I'm wondering about the tradeoff between
having enough error symbols for precision in error reporting
vs. cluttering the code with too many. Thoughts?
-- Bob
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, (continued)
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/03
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Michael Heerdegen, 2021/12/03
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Paul Eggert, 2021/12/04
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/19
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/20
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/20
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/20
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/21
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/23
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/24
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates,
Bob Rogers <=
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/25
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/25
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/26
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/28
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/29
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Paul Eggert, 2021/12/29
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/29
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/30
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/30