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 address@hidden +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--- End Message ---