bug#8782: date command

[Voelker, Bernhard]

Jim Meyering wrote:
> 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.

`date` is still a tool, so I feel it should reflect daily life
... I I don't feel I have a 1h gap in spring, do you? ;-)