[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to calculate date relative to another date?
Re: How to calculate date relative to another date?
Sun, 2 Jun 2019 09:17:53 -0400
On Sat, Jun 01, 2019 at 12:05:29PM -0600, Assaf Gordon wrote:
On Wed, May 22, 2019 at 10:41:52AM -0400, Michael Stone wrote:
In general my advice is to just avoid the date parsing entirely, it will
never, ever do what you predict.
I'm sorry to hear that is your experience with date(1) parsing.
It's not "my experience", it's "my observations based on two decades of
watching people fail to use the tool effectively".
My different advice is to use "date --debug" to first troubleshoot what
is being parsed, then search the mailing list archives for many common
That's sounds a lot like what I wrote below--"if you find something that
happens to work, just copy and paste it and never change it".
If you find something that happens to work,
just copy and paste it and never change it. It would be nice if there were a
new, simple and predictable grammar option in date(1) (abandon the natural
language guessing) but nobody has ever wanted to do the work. :)
The grammar is predictable (though perhaps not trivial) for the simple
reason it is based on a fixed set of rules defined in a GNU Bison
".y" file: https://git.sv.gnu.org/cgit/gnulib.git/tree/lib/parse-datetime.y .
It's *explainable*, or *rationalizable*, but no, for most people it is
not *predictable*. Being written in bison is, I'm sure, a great benefit
for all of the users who are fluent in bison (both of them?) but not a
particularly relevant feature to most. Note that even your own
suggestion--"use 'date --debug' to first troubleshoot"--implies that
people aren't going to get this right the first time (that is, "predict"
correctly) but may possibly be able to rationalize given sufficient
There are no "natural language guessing" algorithms.
Putting in stuff like "last", "this", "first", "next", etc., was
*exactly* an attempt to make the grammar look natural. It turns out to
do a lousy job of this, but it was written 30 years ago with tools from
35 years ago. It would look less natural (but be much more
understandable and predictable) if it worked like other tools that allow
the user to specify parsing patterns explicitly (e.g., strptime) and
used a more explicit mechanism for expressing relative times (e.g.,
python timedelta or postgresql intervals, or any of a dozen similar
It's worth pondering that timeline for a moment--back when this was
written it was using relatively new tools to try something novel.
Something changed, and now we don't use new techniques to try new
things, we just drop the stuff from decades ago into concrete and insist
that they're the best way of doing things--even when the evidence
Instead, and perhap that's the confusing part, there are many attempts
by the parser to match date strings into known meaning.
So, "guessing" based on the user's input expressed in an (apparently)
"natural language"? I guess we can agree that it's an algorithm for
"natural language guessing"! The fact that the guesses are constrained
doesn't make it less of a spooky black box from the perspective of an
end user, and since the date specification string doesn't explicitly
document what's intended it will always be a black box.
NNNN/NN/NN is parsed as YYYY/MM/DD.
NN/NN/NNNN is parsed as MM/DD/YYYY (the north american way).
NNNNNN is parsed as YYMMDD (with YY being 19YY or 20YY with 69 as the
Then similar pattern are matched for time, timezone, and date/time
That's *so much easier and more predictable* than strptime (not).
I would argue that "long term" and "maintainable" is exactly what GNU
date(1) parsing is. You'd be hard-pressed to find programs with
longer-term support than gnu date(1), including python modules.
Again, I'll refer to what I wrote above about "if you find something
that happens to work, just copy and paste it and never change it".
That's long term stability, but *not* maintainability. Non-maintainability
is that thing where someone spends 2 days trying to figure out how to
get date to do what he wants, then sticks it in a script and a few years
later someone else needs to change what's it's doing, spends days
looking at the docs, files a bug report that date isn't working based on
their reading of the docs, and then gets a reply explaining why date(1)
is behaving as expected. I guess we get a gold star because we can
*explain* and *rationalize* what date did, but that doesn't really help
the guy maintain the script because he still can't figure out how to
*predict* the output. And a couple of years later a third guy will find
himself in the same confusing place, starting from scratch.
The confusing and possibly frustrating part happens when trying to mix
different parsing "parts" like date and time and timezone and relative
Sure, that's one of the confusing and frustrating parts.
The "--debug" option should be the first tool to use.
...because the output isn't predictable based on simply reading the
The most common issues are:
You just provided *eight* references to "*some* common issues" but also
want to argue that there are no problems with the grammar that's
implemented? At some point it makes more sense to just admit that the
grammar is a failed experiment and move on to something that people can
understand more easily rather than insisting that *everyone else* just
isn't doing it right. I reached that point at least a decade ago.