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.. [root@schaefer-test ~]# 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.. [root@schaefer-test ~]# 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 <ebl...@redhat.com> wrote: From: Eric Blake <ebl...@redhat.com> Subject: Re: bug#11125: date command calculations are not consistent To: "Thomas R. Schaefer" <schaef...@yahoo.com> Cc: 11...@debbugs.gnu.org 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 Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
