GNU bug report logs - #11125
date command calculations are not consistent

Previous Next

Full log

View this message in rfc822 format

From: "Thomas R. Schaefer" <schaefert <at> yahoo.com>
To: 11125 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: bug#11125: date command calculations are not consistent
Date: Fri, 30 Mar 2012 08:24:48 -0700 (PDT)

[Message part 1 (text/plain, inline)]

Thanks Eric & Bob.  Good stuff.  I'm still slightly foggy on why I get different answers subtracting 35 days from seemingly the same point in time..

[tschaefer <at> schaefer-test ~]$ date  -d 'last Thursday'
Thu Mar 29 00:00:00 CDT 2012
[tschaefer <at> schaefer-test ~]$ date  -d 'Thu Mar 29 00:00:00 CDT 2012 - 35 days'
Wed Feb 22 23:00:00 CST 2012
[tschaefer <at> schaefer-test ~]$ date -d 'last Thursday - 35 days'
Thu Feb 23 00:00:00 CST 2012

But, I'm probably just to dense to get it.

Thanks again for the help.  The suggestion of using "noon today" when subtracting days from a date is an excellent one.

Tom Schaefer

--- On Thu, 3/29/12, Bob Proulx <bob <at> proulx.com> wrote:

From: Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#11125: date command calculations are not consistent
To: "Thomas R. Schaefer" <schaefert <at> yahoo.com>, 11125 <at> debbugs.gnu.org
Date: Thursday, March 29, 2012, 10:35 PM

Eric Blake wrote:
> Thomas R. Schaefer wrote:
> > In this case date does take DST into account in a relative date operation..
> > 
> > [root <at> schaefer-test ~]# date -d "last Thursday - 21 days"
> > Thu Mar  1 00:00:00 CST 2012
> 
> But notice what date -d "last Thursday" is:
> 
> $ TZ=CST date -d 'last Thursday CST'
> Thu Mar 22 00:00:00 CST 2012
> 
> It's relative to the 'CST' timezone, which is an hour different from the
> CDT timezone.

Additionally it is working near the problematic midnight time when
crosing DST boundaries may cause problems.

> > If the date command where being consistent in following the
> > consensus that "relative date operations add or subtract in
> > multiples of 24 hours, without regards to daylight savings
> > boundaries" then both of the above date commands would return Wed
> > Feb 29 23:00:00 CST 2012.
> 
> Only if you start from the same point in time in both commands, which
> you didn't.

For an example always use a time in addition to a day.  Never default
to midnight.  Instead use 12:00 noon to avoid the DST problems.

  $ TZ=US/Mountain date -R -d 'last Thursday'
  Thu, 22 Mar 2012 00:00:00 -0600

That is problematic usage.  But specifying the time as 12:00 noon
solves the problem.

  $ TZ=US/Mountain date -R -d '12:00 last Thursday'
  Thu, 22 Mar 2012 12:00:00 -0600

Then doing calculations will be more reliable.

  $ TZ=US/Mountain date -R -d '12:00 last Thursday - 21 days'
  Thu, 01 Mar 2012 12:00:00 -0700

Note that I always use -R to obtain an unambiguous format.  Using the
default format isn't unambiguous as there are multiple timezones with
the same names.

Doing calculations on weeks and months have similar issues.  When
doing calculations on months I always work with the middle of the
month to avoid the difference in lenghts of months.

Generate a reference date in the middle of the month.

  $ date +%Y-%m-15
  2012-03-15

Use that date for month calculations.

  $ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B.'
  Last month was February.

Please see the FAQ for more examples:

  http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

Unfortunately the human date parsing that was added to date is a
rather simplistic implementation.

Bob

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.