GNU bug report logs - #52209
28.0.60; [PATCH] date-to-time fails on pure dates

Previous Next

Full log

Message #76 received at 52209 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bob Rogers <rogers-emacs <at> rgrjr.homedns.org>
Cc: 52209 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
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.

So how about just adding something that makes parsing common date
formats easier, but without being DWIM or being hard-coded.  Like:

(parse-time "%Y/%m/%d" "2021/01/01")
=> (nil nil nil 01 01 2021)

or something.

It could be regexp-ey

(parse-time "%Y.*%m.*%d" "2021  01-01")

and basically accept the same things that format-time-string accepts,
like:

(with-locale-environment "fr_FR"
  (parse-time "%d +%h" "5 août"))
=> (nil nil nil 5 8 nil)

I think that'd be more generally useful.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.