Subject: bug#35109: date 'tomorrow' bug

From: L A Walsh <[email-masked]>
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.