bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35109: date 'tomorrow' bug


From: Assaf Gordon
Subject: bug#35109: date 'tomorrow' bug
Date: Tue, 2 Apr 2019 20:08:54 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]