bug#11125: date command calculations are not consistent

[Thomas R. Schaefer]

Thank you, I really appreciate your suggestion and will use it in my script.  
That will solve my problem.

I can appreciate the consensus that "relative date operations add or subtract 
in multiples of 24 hours, without regards to daylight savings boundaries".  In 
fact I would be inclined to agree with it.

But if that is the consensus then I believe the date command should adhere to 
that consensus consistently which it does not.

In this case date is calculating with 24 hours days regardless of crossing a 
DST boundary..

address@hidden ~]# date -d "Thu Mar 22 00:00:00 CDT 2012 - 21 days"
Wed Feb 29 23:00:00 CST 2012

In this case date does take DST into account in a relative date operation..

address@hidden ~]# date -d "last Thursday - 21 days"
Thu Mar  1 00:00:00 CST 2012

If the date command where being consistent in following the consensus that 
"relative date operations add or subtract in multiples of 24 hours, without 
regards to daylight savings boundaries" then both of the above date commands 
would return Wed Feb 29 23:00:00 CST 2012.

Again thank you for your help,

Tom Schaefer










--- On Thu, 3/29/12, Eric Blake <address@hidden> wrote:

From: Eric Blake <address@hidden>
Subject: Re: bug#11125: date command calculations are not consistent
To: "Thomas R. Schaefer" <address@hidden>
Cc: address@hidden
Date: Thursday, March 29, 2012, 1:01 PM

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