GNU bug report logs - #12772
date : Bug in handling human readable dates

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12772 in the body.
You can then email your comments to 12772 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Guido Ackermann <ga <at> alexandersfeld.de>
To: bug-coreutils <at> gnu.org
Subject: date : Bug in handling human readable dates
Date: Wed, 31 Oct 2012 11:00:22 +0100

Hello,
today i discovered a bug in the programm "date" handling human readable timeformats.
The bug:

# date --version
date (GNU coreutils) 8.5

# export LC_ALL="C" ;date
Wed Oct 31 10:57:06 CET 2012
# export LC_ALL="C" ;date -d"last month"
Mon Oct  1 11:57:23 CEST 2012
# export LC_ALL="C" ;date -d"next month"
Sat Dec  1 10:57:35 CET 2012

While aktual monthh is still Oct, previous month is shown as Oct too, and next month is shown as Dec.
Correctly "last month" should be Sep. "next month" should be Nov. 

regards,
	Guido Ackermann

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

From: Bob Proulx <bob <at> proulx.com>
To: Guido Ackermann <ga <at> alexandersfeld.de>
Cc: 12772 <at> debbugs.gnu.org
Subject: Re: bug#12772: date : Bug in handling human readable dates
Date: Wed, 31 Oct 2012 13:42:08 -0600

tag 12772 + notabug moreinfo
thanks

Guido Ackermann wrote:
> today i discovered a bug in the programm "date" handling human
> readable timeformats.

Thank you for the bug report.  And also thank you very much for
including the version you are using.  However you are tripping over a
common misconception about date.

> # export LC_ALL="C" ;date
> Wed Oct 31 10:57:06 CET 2012

In addition to LC_ALL please tell us what timezone you are using.  The
timezone string is ambiguous and CET may not be unique.  Better is to
use the -R format to get a standard unambiguous format.  Best is to
use UTC which avoids all of those issues.  You can do both on the
command without 'export'.  Using 'env' is the canonical method across
all shells.  For example:

  $ env LC_ALL=C TZ=Europe/Berlin date -R

> # export LC_ALL="C" ;date -d"last month"
> Mon Oct  1 11:57:23 CEST 2012

  $ env LC_ALL=C TZ=Europe/Berlin date -R -d "last month"
  Mon, 01 Oct 2012 21:36:34 +0200

> # export LC_ALL="C" ;date -d"next month"
> Sat Dec  1 10:57:35 CET 2012

  $ env LC_ALL=C TZ=Europe/Berlin date -R -d "next month"
  Sat, 01 Dec 2012 20:35:55 +0100

> While aktual monthh is still Oct, previous month is shown as Oct
> too, and next month is shown as Dec.
> Correctly "last month" should be Sep. "next month" should be Nov. 

Yes.  However this behavior is documented.  See the manual for the
full documentation.  Here are some sections from it:

     The unit of time displacement may be selected by the string `year'
  or `month' for moving by whole years or months.  These are fuzzy units,
  as years and months are not all of equal duration.  More precise units
  are `fortnight' which is worth 14 days, `week' worth 7 days, `day'
  worth 24 hours, `hour' worth 60 minutes, `minute' or `min' worth 60
  seconds, and `second' or `sec' worth one second.  An `s' suffix on
  these units is accepted and ignored.
  ...
     The fuzz in units can cause problems with relative items.  For
  example, `2003-07-31 -1 month' might evaluate to 2003-07-01, because
  2003-06-31 is an invalid date.  To determine the previous month more
  reliably, you can ask for the month before the 15th of the current
  month.  For example:

       $ date -R
       Thu, 31 Jul 2003 13:02:39 -0700
       $ date --date='-1 month' +'Last month was %B?'
       Last month was July?
       $ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B!'
       Last month was June!

     Also, take care when manipulating dates around clock changes such as
  daylight saving leaps.  In a few cases these have added or subtracted
  as much as 24 hours from the clock, so it is often wise to adopt
  universal time by setting the `TZ' environment variable to `UTC0'
  before embarking on calendrical calculations.

Please also see the FAQ where this issue is discussed at some length.

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

Does that sufficiently answer your issue?

Bob

Message #15 received at 12772-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: ga <at> alexandersfeld.de
Cc: 12772-done <at> debbugs.gnu.org
Subject: Re: bug#12772: date : Bug in handling human readable dates
Date: Wed, 31 Oct 2012 13:51:31 -0600

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

tag 12772 notabug
thanks

On 10/31/2012 04:00 AM, Guido Ackermann wrote:
> Hello,
> today i discovered a bug in the programm "date" handling human readable timeformats.
> The bug:
> 
> # date --version
> date (GNU coreutils) 8.5
> 
> # export LC_ALL="C" ;date
> Wed Oct 31 10:57:06 CET 2012
> # export LC_ALL="C" ;date -d"last month"
> Mon Oct  1 11:57:23 CEST 2012
> # export LC_ALL="C" ;date -d"next month"
> Sat Dec  1 10:57:35 CET 2012
> 
> While aktual monthh is still Oct, previous month is shown as Oct too, and next month is shown as Dec.
> Correctly "last month" should be Sep. "next month" should be Nov. 

Thanks for the report.  However, this is the result of daylight savings
impacting the calculations.  "last month" and "next month" translate to
a fixed number of 24-hour jumps, but since you are in a month with a
25-hour day, you still end up in October when going backwards, and skip
over the 30 days of November when going forwards.

This is a FAQ:
https://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

There, we give suggestions on how to avoid the ambiguities, such as by
starting at noon rather than midnight when jumping by days, or using the
15th instead of the first or last of a month when jumping by months, in
order to guarantee that the result lands in the desired granularity in
spite of the non-uniformity caused by daylight savings or changing
numbers of days per month.  The FAQ also suggests using UTC instead of
local timezone to avoid daylight savings issues.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Nemo Maelstrom Thorx <debianbug <at> nemo.house.cx>
To: 12772 <at> debbugs.gnu.org
Subject: Re: bug#12772: date : Bug in handling human readable dates
Date: Thu, 1 Nov 2012 12:07:47 +1000

Coincidentally, I found this bug just today also, and whilst
I acknowledge the workarounds if the only thing you need is the month,
sometimes you need the relative position within the month also.

I would suggest that the end of march's -1month would more intuitively
map to the end of february, repeated. ie, "lock" the month in, and
adjust the "least significant" part - the day. 

Same sort of unintuitive results can occur with requesting +1 month, or
even +/-1year from February 29. 


I also thought it might be illuminating to see how other systems handle
this ambiguity.

mysql> SELECT DATE_SUB('2012-03-31', INTERVAL 1 MONTH);
+------------------------------------------+
| DATE_SUB('2012-03-31', INTERVAL 1 MONTH) |
+------------------------------------------+
| 2012-02-29                               |
+------------------------------------------+
1 row in set (0.00 sec)

Colleagues inform me that postgresql behaves this way also, alongside
python's mx.DateTime library (and ms-sql too).

Conversely, sqlite, php behave like 'date' :)

.../Nemo

-- 
  ----------------------------------------- -----------------------------
                                                    earth native




-- 
  ----------------------------------------- -----------------------------
                                                    earth native

Previous Next

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