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.
