[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to calculate date relative to another date?

From: Michael Stone
Subject: Re: How to calculate date relative to another date?
Date: Sun, 2 Jun 2019 09:17:53 -0400
User-agent: NeoMutt/20170113 (1.7.2)

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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]