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

Previous Next

Full log

View this message in rfc822 format

From: Bob Rogers <rogers-emacs <at> rgrjr.homedns.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 52209 <at> debbugs.gnu.org, Paul Eggert <eggert <at> 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

   From: Lars Ingebrigtsen <larsi <at> 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 <at> 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

Previous Next

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