Re: How to calculate date relative to another date?

[Assaf Gordon]

Hello,

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.

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, and lastly, write to address@hidden with questions.

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

There are no "natural language guessing" algorithms.

Instead, and perhap that's the confusing part, there are many attempts
by the parser to match date strings into known meaning.

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.

The different formats and patterns are explained here:
https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html#Date-input-formats

> You might try "2018-05-01 59 months ago", but I'd suggest using a python
> module or somesuch with a more regular grammar if you want something
> maintainable in the long term.

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.

The confusing and possibly frustrating part happens when trying to mix
different parsing "parts" like date and time and timezone and relative
time calculations.

The "--debug" option should be the first tool to use.

The most common issues are:

Crossing daylight-saving-time (getting unexpected "tomorrow" results):
https://lists.gnu.org/archive/html/bug-coreutils/2019-04/msg00003.html
https://lists.gnu.org/archive/html/bug-coreutils/2016-04/msg00046.html
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30795

Mixing time and time-zones:
https://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00126.html

Months-related adjustments:
https://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00357.html

General adjustments, and order of operations:
https://lists.gnu.org/archive/html/bug-coreutils/2018-02/msg00005.html

Leap years and such:
https://lists.gnu.org/archive/html/bug-coreutils/2017-03/msg00047.html

Inner-working of date adjustments:
https://lists.gnu.org/archive/html/bug-coreutils/2017-03/msg00044.html

Hope this helps,
 -assaf