From: Bob Rogers <rogers-emacs@rgrjr.homedns.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 52209@debbugs.gnu.org
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Date: Fri, 24 Dec 2021 10:58:53 -0500 [thread overview]
Message-ID: <25029.60989.564217.290743@orion.rgrjr.com> (raw)
In-Reply-To: <87zgoq2vwm.fsf@gnus.org>
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
next prev parent reply other threads:[~2021-12-24 15:58 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-30 20:55 bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates Bob Rogers
2021-12-01 4:17 ` Lars Ingebrigtsen
2021-12-03 5:19 ` Katsumi Yamaoka
2021-12-03 16:29 ` Lars Ingebrigtsen
2021-12-03 18:38 ` Michael Heerdegen
2021-12-04 18:58 ` Paul Eggert
2021-12-19 21:11 ` Bob Rogers
2021-12-20 10:08 ` Lars Ingebrigtsen
2021-12-20 15:57 ` Bob Rogers
2021-12-20 16:34 ` Bob Rogers
2021-12-21 11:01 ` Lars Ingebrigtsen
2021-12-23 19:48 ` Bob Rogers
2021-12-24 9:29 ` Lars Ingebrigtsen
2021-12-24 15:58 ` Bob Rogers [this message]
2021-12-25 11:58 ` Lars Ingebrigtsen
2021-12-25 22:50 ` Bob Rogers
2021-12-26 11:31 ` Lars Ingebrigtsen
2021-12-28 15:52 ` Bob Rogers
2021-12-29 15:19 ` Lars Ingebrigtsen
2021-12-29 19:29 ` Paul Eggert
2021-12-29 22:01 ` Bob Rogers
2021-12-30 5:32 ` Bob Rogers
2021-12-30 21:08 ` Bob Rogers
2022-01-01 14:47 ` Lars Ingebrigtsen
2022-01-01 14:56 ` Andreas Schwab
2022-01-02 0:41 ` Bob Rogers
2022-01-03 11:34 ` Lars Ingebrigtsen
2022-01-04 4:45 ` Bob Rogers
2022-01-05 15:46 ` Lars Ingebrigtsen
2022-01-05 22:49 ` Bob Rogers
[not found] ` <25105.33397.961104.269676@orion.rgrjr.com>
2022-02-20 12:25 ` Lars Ingebrigtsen
2022-02-20 13:03 ` Andreas Schwab
[not found] ` <87ilt9vicd.fsf@gnus.org>
2022-02-20 22:14 ` Bob Rogers
2022-02-23 23:15 ` Bob Rogers
2022-02-24 9:19 ` Lars Ingebrigtsen
2022-02-25 0:49 ` Bob Rogers
2022-02-25 2:16 ` Lars Ingebrigtsen
2022-02-25 2:32 ` Bob Rogers
2022-02-25 2:58 ` Bob Rogers
2022-02-25 12:03 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25029.60989.564217.290743@orion.rgrjr.com \
--to=rogers-emacs@rgrjr.homedns.org \
--cc=52209@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.