Re: How to calculate date relative to another date?

[Michael Stone]

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
> solutions, 

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 
*additional data*. 

> 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 
examples). 

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 
suggests otherwise.

> 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. 

> For example,
> 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
> cutoff).
>
> Then similar pattern are matched for time, timezone, and date/time
> adjustments.

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
> time calculations.

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 
(voluminous) documentation.

> The most common issues are:
[snip]

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.

Mike Stone