GNU bug report logs - #44865
date recalculation error

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 44865 in the body.
You can then email your comments to 44865 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: Ruder Laplace <ruder.email <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: date recalculation error
Date: Wed, 25 Nov 2020 10:54:45 +0100

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

Greetings,

I think I catched a bug related to the day-light saving gap:
*uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
Linux ******** 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
GNU/Linux
mié nov 25 10:30:29 CET 2020
lun jun  1 *12*:00:00 CEST 2020

As far as I think it should work, the expected result should be: lun jun 1
*11*:00:00 CEST 2020
"One hour after 10" is 11, not 12.

I'm not sure if it has something to do to be right now in UTC+1 and the
other time un UTC+2, but I don't remember having any trouble while in DL
saving while on UTC+2.

To me, the intuitive way is the one the program worries about whether DL
saving was/will be ON on the specified time.

*date --version*
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.

*lsb_release -a*
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

Thanks for your time,
Ruder Laplace.

[Message part 2 (text/html, inline)]

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

From: "Rainer M. Canavan" <coreutils <at> canavan.de>
To: ruder.email <at> gmail.com
Cc: 44865 <at> debbugs.gnu.org
Subject: Re: bug#44865: date recalculation error
Date: Wed, 25 Nov 2020 14:48:40 +0100 (CET)

Ruder Laplace <ruder.email <at> gmail.com> wrote:
> Greetings,
> 
> I think I catched a bug related to the day-light saving gap:
> *uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
> Linux ******** 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
> GNU/Linux
> mié nov 25 10:30:29 CET 2020
> lun jun  1 *12*:00:00 CEST 2020
> 
> As far as I think it should work, the expected result should be: lun jun 1
> *11*:00:00 CEST 2020
> "One hour after 10" is 11, not 12.


You can check how date interprets your string using --debug:

$ date -d "2020/06/01 11:00:00 +1 hour" --debug 
date: warning: value 2020 has 4 digits. Assuming YYYY/MM/DD
date: parsed date part: (Y-M-D) 2020-06-01
date: parsed time part: 11:00:00 UTC+01
date: parsed relative part: +1 hour(s)
date: input timezone: parsed date/time string (+01)
date: using specified time as starting value: '11:00:00'
date: starting date/time: '(Y-M-D) 2020-06-01 11:00:00 TZ=+01'
date: '(Y-M-D) 2020-06-01 11:00:00 TZ=+01' = 1591005600 epoch-seconds
date: after time adjustment (+1 hours, +0 minutes, +0 seconds, +0 ns),
date:     new time = 1591009200 epoch-seconds
date: timezone: system default
date: final: 1591009200.000000000 (epoch-seconds)
date: final: (Y-M-D) 2020-06-01 11:00:00 (UTC)
date: final: (Y-M-D) 2020-06-01 13:00:00 (UTC+02)
Mo 1. Jun 13:00:00 CEST 2020


As you can see, it assumes that the "+1" indicates the timezone, which
is 1 hour behind your local zone, thus 11:00 there would actually be 12:00
in your time zone. The "hour" alone is then used as a +1 hour adjustment,
resulting in 13:00 CEST. Commands that work as you expected:

$ date -d "2020/06/01 11:00:00 1 hour" --debug
$ date -d "2020/06/01 11:00:00 +1 +1 hour" --debug
$ date -d "2020/06/01 11:00:00 CEST +1 hour" --debug
$ date -d "+1 hour 2020/06/01 11:00:00" --debug

rainer

Previous Next

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