bug#8782: date command

[Jim Meyering]

Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> Voelker, Bernhard wrote:
>>> Jim Meyering wrote:
>>>> James Youngman wrote:
>>>>
>>>>> One tweak: use date -d "12:00 +1 day" instead of "date -d tomorrow" in
>>>>> the example.
>>>>
>>>> Good idea.  That makes it immune to failure in a one hour interval
>>>> on the day before the spring DST transition.
>>>
>>> hmm, shouldn't the "tomorrow" handling be fixed then?
>>
>> Hi Voelker,
>>
>> "Fixed" how?  To retry in that very unusual case?
>> Let's ignore that someone might depend on the current failure,
>> e.g., to locate a DST transition.
>
> that's BAD (tm) usage, IMHO
>
>> Note that "tomorrow" is equivalent to "+1 day", aka "+24 hours".
>
>> Upon retry would you use +23 hours or +25 hours?  Something else?
>
>> I don't think it's feasible to change it.
>
> I admit it's hard.
>>From the user's point of view, there's always a date "24 hours from now on".
> And the user wants to know what date this would be ...

We can't change the fact that the spring DST transition
introduces a one-hour hole containing invalid times.
Whenever we tell "date" to use a time in such a hole,
date must diagnose it as invalid.

>> This is well documented in the FAQ, and probably in the manual, too.
>
> yes, it is. But as I'm following this ML for ~2 years now, this topic
> has popped up several times. It seems there's room for improvement.

Making a technical change will be a challenge, to say the least.

People are learning that this hole can make date fail.
As I see it, education is the way to go.