[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11125: date command calculations are not consistent
From: |
Eric Blake |
Subject: |
bug#11125: date command calculations are not consistent |
Date: |
Thu, 29 Mar 2012 12:01:47 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0 |
forcemerge 11098 11125
thanks
On 03/29/2012 11:43 AM, Thomas R. Schaefer wrote:
> Discovered this when I script I have cronned to run at 12:01AM gave some
> unexpected results.
>
> After much picking at it I finally figured out that the date command itself
> was the source of my problem. It isn't handling date calculations that span
> the daylight savings time change consistently
Thanks for the report. Join the club. This has been reported twice
this week already, and the consensus is that date is behaving as
documented (relative date operations add or subtract in multiples of 24
hours, without regards to daylight savings boundaries), but that the
documented behavior could be improved if someone were to submit a patch.
https://lists.gnu.org/archive/html/bug-coreutils/2012-03/msg00102.html
As recommended in our FAQ,
https://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
it's almost always better to base relative time computations off of noon
rather than midnight (as both 11 am and 1 pm fall in the same day, even
when your multiple-of-24-hours crosses a 23-hour or 25-hour day).
In your example, change:
RSD="$(date +%F -d "today - 35 days")" # Report Start Date
to:
RSD="$(date +%F -d "noon today - 35 days")" # Report Start Date
--
Eric Blake address@hidden +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature