GNU bug report logs - #15785
Problem with incrementing date when clock goes back

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15785 in the body.
You can then email your comments to 15785 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Samuel Penn <spenn <at> perforce.com>
To: bug-coreutils <at> gnu.org
Subject: Problem with incrementing date when clock goes back
Date: Fri, 1 Nov 2013 15:21:37 +0000 (GMT)

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.

Running the following gives unexpected results:

# date -s "2013/10/27 00:00:00"
Sun Oct 27 00:00:00 BST 2013
# date --date="+1 day"
Sun Oct 27 23:00:04 GMT 2013
# date --date="tomorrow"
Sun Oct 27 23:00:08 GMT 2013

I would expect that both "+1 day" and "tomorrow" to move the date
to the next day, but neither do so.

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.

This issue seems to have been raised (and 'fixed') before:

http://lists.gnu.org/archive/html/bug-coreutils/2003-09/msg00001.html


The version of date/coreutils seems to be: GNU coreutils 8.12.197-032bb

I'm running Ubuntu 12.04

-- 
Samuel Penn
Software Engineer
Perforce Software


--------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. Please 
note that any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Perforce Software. Finally, 
the recipient should check this email and any attachments for the presence of 
viruses. Perforce Software accepts no liability for any damage caused by any 
virus transmitted by this email.

Perforce Software UK Ltd is registered in England and Wales as company no. 
3816019 at the following address: West Forest Gate, Wellington Road, Wokingham,
RG40 2AT, UK
--------------------------------------------------------------------------------

Message #8 received at 15785 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Samuel Penn <spenn <at> perforce.com>, 15785 <at> debbugs.gnu.org
Subject: Re: bug#15785: Problem with incrementing date when clock goes back
Date: Fri, 01 Nov 2013 10:26:34 -0600

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 15785 <at> debbugs.gnu.org (full text, mbox):

From: Samuel Penn <spenn <at> perforce.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15785 <at> debbugs.gnu.org
Subject: Re: bug#15785: Problem with incrementing date when clock goes back
Date: Fri, 1 Nov 2013 16:54:08 +0000 (GMT)

Eric Blake wrote: 
> 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.

I did have a skim through that, but I didn't see the "tomorrow"
issue mentioned for DST changes.

Setting to Noon does mean you lose the current time, in the case
when you want to preserve time (as best as possible) and just
change the day.

It does feel very wrong that "tomorrow" doesn't always give 
tomorrow. It would seem better to give an unexpected time in this
case, rather than an unexpected day. IMO.

> 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).

Hmm, I wonder why that is.

Okay, thanks for taking the time to respond.

-- 
Samuel Penn
Software Engineer
Perforce Software



--------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. Please 
note that any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Perforce Software. Finally, 
the recipient should check this email and any attachments for the presence of 
viruses. Perforce Software accepts no liability for any damage caused by any 
virus transmitted by this email.

Perforce Software UK Ltd is registered in England and Wales as company no. 
3816019 at the following address: West Forest Gate, Wellington Road, Wokingham,
RG40 2AT, UK
--------------------------------------------------------------------------------

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.