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
signature.asc
Description: OpenPGP digital signature
