[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8782: date command

From: Jim Meyering
Subject: bug#8782: date command
Date: Fri, 03 Jun 2011 11:15:21 +0200

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]