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

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 35109 in the body.
You can then email your comments to 35109 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: Maximilian Gleißner
 <maximilian.gleissner <at> onevision.com>
To: bug-coreutils <at> gnu.org
Subject: date 'tomorrow' bug
Date: Tue, 2 Apr 2019 15:23:55 +0200

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

Hi,

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.

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

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

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


Regards
M.Gleissner

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

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Maximilian Gleißner
 <maximilian.gleissner <at> onevision.com>
Cc: 35109 <at> debbugs.gnu.org
Subject: Re: bug#35109: date 'tomorrow' bug
Date: Tue, 02 Apr 2019 17:15:17 -0700

On 4/2/2019 6:23 AM, Maximilian Gleißner wrote:
> Hi,
>
> 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.
>
> 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
>
> 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:X
I suppose it would depend on your definition of tomorrow.  I don't
know if it has a locale specific definition.

Is "24 hours from now", or is it the whole day from midnight->midnight,
or is it the same time "X" hours past midnight.

You are using a "same time tomorrow" which, by definition would
be the same time with date+1, but if you use 24 hours ahead, or same #
hours past midnight, or the entire period from day-start to day-end,
you wouldn't get the answer you expected.

I don't know if 'tomorrow' is supposed have meaning of same-time, but
more 1 day ahead of now, which would tend toward 24 hours.

I'm not saying I agree or disagree, just that in my mind, the word
tomorrow seems a bit vaguely defined, but turning to google
and asking for define tomorrow, I get
1) on the day after today, or
   the day after today.

In both cases it refers to 'the day' not a particular number of hours
in the future.

The fact that you can type in tomorrow at all is a bit surprising
given the common definition which never refers to a specific time,
but the entirety.  Even so, the answer you show, intuitively seems
off -- but I don't know that our intuition knows about Daylight savings
time.

I'd be more likely to suggest that tomorrow shouldn't return a time
at all, but only a date, which would be the current data incremented
by one.  Somewhere along the line it looks like someone thought to
"compute" tomorrow as if it was some exact quantity 24 hours in the
future -- which doesn't fit any of the most frequently used definitions
I see.

I.e. expected output:
2019-04-01
(no time).

It's always the case that people need to specify a time when referring
to yesterday, today or tomorrow.  Tomorrow wouldn't be 24 hours ahead
of now anymore than today means 'now'.

Just my 2 cents.

There's probably some inane definition of tomorrow defined by
POSIX, but of course, you'd need to specify which POSIX version you
are referring to as there is more than one definition of the
since they do change over time.


> I am aware you recommend not using local timezones and daylight savings 
> time, but I still think this should/could be implemented better.
>   
----
    Who is 'you' in this context, Gnu, POSIX, SuSE or ???
Seems odd to tell people not to use something that most computers
likely do automatically these days.

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.