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? ;-)