On 11/01/2013 09:21 AM, Samuel Penn wrote:
> 
> The "date" command seems to have a problem when the clock goes back. 
> Last Sunday (27th October 2013), the time changed from BST to GMT, 
> so we had a day with 25 hours in it.

Yep.  And it is a FAQ that 25-hour days mess with relative date
calculations:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

The FAQ also suggests basing your computations around noon rather than
midnight, so that even the fuzz of daylight savings won't get in the way
of you landing in the correct day.

> Whilst I can accept that "+1 day" actually adds 24 hours (and
> therefore gives the above result), I would always expect "tomorrow"
> to give tomorrow, regardless of time changes, and regardless of the
> current time.

You are welcome to submit a patch to change the date parser (now
maintained in gnulib) to attempt that.  But even in the current sources,
"tomorrow" applies a tDAY_SHIFT of 1, but after applying the shift, we
then perform timezone normalization, which ends up treating the shift as
only 24 hours.

> 
> This issue seems to have been raised (and 'fixed') before:
> 
> http://lists.gnu.org/archive/html/bug-coreutils/2003-09/msg00001.html

Thanks for digging up that thread; it corresponds to commit 54feed1c,
released in coreutils 5.0.91.  I'd have to do more investigation
(actually building 5.0.90 and 5.0.91 to compare how they behaved) to see
if it made a difference then, and if so, if we have regressed in the
meantime.  Hence, I'm leaving this bug open a bit longer (even though it
is just one of many bug reports on the theme that typically appear twice
a year).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org