date manupulation strangeness

Miguel Lopes Santos Ramos miguel at
Wed Oct 31 15:48:12 PDT 2007

> From: Mike Pritchard <mpp at>
> DST/CST time changes when setting the time backwards has been at your
> own risk for a long time.

Yes, but there's really not much reason for it to be so much of a black art.
Actually, I think the old behaviour, prior to rev 1.36, although not ideal was
quite reasonable: it interpreted the user supplied date in the current time zone,
say winter time, even though it refered to a period of summer time.
It was that change that introduced a behaviour which IMHO must be regarded
as a bug.

> Back in 1995/6 when I fixed a lot of utilities to enforce the password
> expiration date/time, I found it was off by +/- 1 hour if I was setting
> dates and times that would cross DST changes.  Not a big deal then,
> but I think I got them all to work correctly.

Well, the line of code I objected to is not that old.
CVS blames someone called ru on revision 1.36 who committed changes
submitted by Crist Clark in 2001.

> But if I recall correctly, if you wanted to really test those type of
> changes by setting the system date/time back, it was better to set
> the date/time to a period well before the DST change, verify the system
> understood it was in the proper time zone (probably a reboot),
> THEN move the clock up to just before the DST time change and let it 
> roll over.

There's not much point in doing that in this case, is there?
All that is at stake here is if date translates from user supplied dates into
a time_t in a predictable/justifiable manner.
If it does/doesn't, rebooting and letting time pass won't do much good.

The reason why I think that that must be seen as a bug is that date gave
surprising results in a case where the user provided unmistakable input.

Allow me to recall Eugene Grosbein / Holger Kipp's test case:

> %setenv LC_ALL C
> %setenv TZ Asia/Krasnoyarsk
> %setenv unixtime 1193511599
> %date -jr $unixtime
> Sun Oct 28 02:59:59 KRAST 2007
> %date -jf %s $unixtime
> Sun Oct 28 02:59:59 KRAT 2007

As you can see, the input to date is unmistakable, it is a time_t.
The difference is that the second case forces date to use strptime() and
the first doesn't.

date is not outputing only the timezone wrong, those two dates are one hour
appart. That means that in the first date is understanding 1193511599,
and that in the second, at one point in its execution, date is understanding
1193615199, one hour latter. Trust me or add a printf to line 273.

The line which is the cause for this misinterpretation is line 268.
Before that line was introduced, behaviour was justifiable, although not ideal.
If the user supplied unmistakable input, either a time_t or a date with
explicit timezone, it worked, and when the user supplied date without timezone
it always understood the date in the current timezone. This only had the
inconvenient of +1/-1 when done across DST, but at least it wouldn't throw
away the information supplied by the user.

This line also makes date misinterpret full dates with timezone,
not only time_ts for that limbo hour.

In my opinion, we can have a bugless date for the limbo hour, and still
solve the +1/-1 inconvenient simply by not destroying strptime()'s output.
All it takes is to move 268 to line 191, as I said before.

Of course, I don't think this is a critical or prioritary issue, not at all.
It was only fun, because I could look into it in a half hour.
But the kludge to solve the +1/-1 inconvenient is there and is ugly.



More information about the freebsd-stable mailing list