Subject: bug#11125: date command calculations are not consistent

From: Eric Blake <[email-masked]>
Date: Thu, 29 Mar 2012 12:01:47 -0600

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   [email-masked]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org