GNU bug report logs - #35109
date 'tomorrow' bug

Previous Next

Full log

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Maximilian Gleißner
 <maximilian.gleissner <at> onevision.com>, 35109 <at> debbugs.gnu.org
Subject: Re: bug#35109: date 'tomorrow' bug
Date: Tue, 2 Apr 2019 20:08:54 -0600

tags 35109 notabug
close 35109
stop

Hello,

On 2019-04-02 7:23 a.m., Maximilian Gleißner wrote:
> I have encountered a possible bug with the date function using both SuSE
> LEAP 15.0 and SuSE 10.2.
> This bug occurs when asking date for 'tomorrow' when there is a daylight
> saving timechange.

This is not a bug, just a usage issue.

> Note: The machine is located in the GMT+1 timezone, and daylight savings
> time changed on 31.03.2019 02:00 jumping to 03:00

Exactly - and 'date' adjust the time accordingly by adding
an hour if the timezone was crossed.
(technically it's not date(1) but glibc, if that matters).

> To replicate the bug:
> date -s "2019-03-30 23:XX"                      #where XX is any valid
> minute, e.g. 23:35
> date -d 'tomorrow'                              #expected output:
> 2019-03-31 23:XX
> actual output: 2019-04-01 00:XX

Note that 'date' printed one more critical piece of information:

   $ date
   Sat Mar 30 23:10:41 GMT 2019

   $ date -d tomorrow
   Mon Apr  1 00:10:43 BST 2019

The timezone shifted from GMT to BST - and the time was adjusted 
accordingly by adding an hour, and crossing into April 1st.

Similarly, if you waited 5 hours from 2019-03-30 23:35
it would be 5am, not 4am - and date needs to account for that:

    $ date
    Sat Mar 30 23:18:47 GMT 2019
    $ date -d "+5 hours"
    Sun Mar 31 05:18:49 BST 2019


> I am aware you recommend not using local timezones and daylight savings
> time, but I still think this should/could be implemented better.
> 

The GNU coreutils team does not recommend such a thing at all.
In fact, team member Prof. Paul Eggert is the editor maintainer of the
Time Zone database ( https://en.wikipedia.org/wiki/Tz_database ) which
is used by almost every operating system and many programming languages
( https://en.wikipedia.org/wiki/Tz_database#Use_in_software_systems ).

There is a strong recommendation however, to specify "noon" (12pm)
whenever doing date arithmetics, exactly to avoid DST issues.
See:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

  $ date
  Sat Mar 30 23:24:08 GMT 2019

  $ date -d "12pm tomorrow"
  Sun Mar 31 12:00:00 BST 2019

On the other hand, it is the European Union that wants to do away
with daylight saving time:
https://www.bbc.com/news/world-europe-45366390

To learn more about the inner-working of GNU date
and similar issues with DST, please see past discussions here:
  https://bugs.gnu.org/8357
  https://bugs.gnu.org/11101
  https://bugs.gnu.org/18159
  https://bugs.gnu.org/30795


As such, I'm marking this as "not a bug", but discussion can continue by
replying to this thread.

regards,
 - assaf

Previous Next

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