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@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org