From: Bob Rogers <rogers-emacs@rgrjr.homedns.org>
To: Lars Ingebrigtsen <larsi@gnus.org>,
Andreas Schwab <schwab@linux-m68k.org>
Cc: 52209@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Date: Sat, 1 Jan 2022 19:41:26 -0500 [thread overview]
Message-ID: <25040.62646.635818.692654@orion.rgrjr.com> (raw)
In-Reply-To: <87lezz5x92.fsf@gnus.org>
From: Lars Ingebrigtsen <larsi@gnus.org>
Date: Sat, 01 Jan 2022 15:47:05 +0100
I wonder whether we should look at this another way. We currently have
two built-in date parsing functions in Emacs: `iso8601-parse' and
`parse-time-string', and both parse strings according to well-defined
standards (ISO8601 and RFC822bis, respectively). (But the latter's doc
string didn't explicitly say so, so people thought it was a DWIM
parser.)
DWIM date parsing is impossible, though, because there's an infinite
variety of date formats out there, and variants are ambiguous. And
adding an infinite number of date parsers to Emacs doesn't seem
attractive.
After perusing [1], I had started to think in terms just three basic
formats: dmy (formerly euro-date), ymd, and mdy (formerly us-date),
plus possibly adding "." as a date separator. That doesn't cover
everything but ought to broaden the set to make most of the world happy,
especially if I add a few hacks I have in mind to broaden recognition of
four-digit years and alphabetic months. The rest I think could be left
to "patches welcome."
And in that context, it may make more sense to say, "Use the original
parse-time-string if you know you have email dates, or iso8601-parse if
you have dates that conform to ISO-8601," rather than having parse-date
handle them itself.
So how about just adding something that makes parsing common date
formats easier, but without being DWIM or being hard-coded . . .
I think that'd be more generally useful.
Perhaps, but I see that as a different problem: One where you have a
date or set of dates in a precise format and just need to knock them
out. I was trying to solve the problem where you have date(s) that you
only know the general origin (e.g. North America) and don't know whether
they are numeric, alphabetic, or how precise, and just want the parser
to do the best it can, and signal a reasonably informative error rather
than return an incorrect result.
================
From: Andreas Schwab <schwab@linux-m68k.org>
Date: Sat, 01 Jan 2022 15:56:37 +0100
On Jan 01 2022, Lars Ingebrigtsen wrote:
> (parse-time "%Y/%m/%d" "2021/01/01")
> => (nil nil nil 01 01 2021)
Aka strptime.
Oh, you're talking about the POSIX strptime, not the Perl Date::Parse
strptime, which is free-form. Not being a C programmer, I was not aware
of the POSIX version. But now I know where the odd name came from. ;-}
-- Bob
[1] https://en.wikipedia.org/wiki/Date_format_by_country
next prev parent reply other threads:[~2022-01-02 0:41 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
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 [this message]
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=25040.62646.635818.692654@orion.rgrjr.com \
--to=rogers-emacs@rgrjr.homedns.org \
--cc=52209@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=larsi@gnus.org \
--cc=schwab@linux-m68k.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.