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

Previous Next

Package: coreutils;

Reported by: "Thomas R. Schaefer" <schaefert <at> yahoo.com>

Date: Thu, 29 Mar 2012 18:21:01 UTC

Severity: normal

Tags: notabug

Merged with 11098, 11101, 15785, 18159, 18479, 20523

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #19 received at 11125 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Thomas R. Schaefer" <schaefert <at> yahoo.com>, 11125 <at> debbugs.gnu.org
Subject: Re: bug#11125: date command calculations are not consistent
Date: Thu, 29 Mar 2012 21:35:55 -0600
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





This bug report was last modified 6 years and 211 days ago.

Previous Next


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