[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: Assaf Gordon
Subject: Re: How to calculate date relative to another date?
Date: Sat, 1 Jun 2019 12:05:29 -0600
User-agent: Mutt/1.11.4 (2019-03-13)


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

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

Then similar pattern are matched for time, timezone, and date/time

The different formats and patterns are explained here:

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

Mixing time and time-zones:

Months-related adjustments:

General adjustments, and order of operations:

Leap years and such:

Inner-working of date adjustments:

Hope this helps,

reply via email to

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