cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c

[M. Warner Losh]

In message: <20051021011035.T1945 at delplex.bde.org>
            Bruce Evans <bde at zeta.org.au> writes:
: > You can by definition not implment difftime correctly since the
: > time_t timescale does not contain any indication of leapseconds.
: >
: > This means that there is no way to tell which side of an inserted
: > leapsecond a time(2) timestamp comes from:
: >
: > 	UTC		time(2)
: > 	23:59:57	N-3
: > 	23:59:58	N-2
: > 	23:59:59	N-1
: > 	23:59:60	N
: > 	00:00:00	N
: > 	00:00:01	N+1
: >
: > Worst case, difftime() will be wrong by two seconds: taking the difference
: > from one leapsecond to another and guessing wrong in both ends.
: 
: It only has to be wrong by 1 or 2 seconds for short intervals when a leap
: seconds occurs.  Not adjusting makes difftime() wrong across all intervals
: containing a leap second, with an error of the number of leap seconds in
: the interval (+- 1 or 2 for leap seconds at endpoints).

Where do you keep the table of leapseconds?  How do you make sure it
gets updated?  As far as I know, there's no installed leap second data
on the system, unless you've enabled the 'run in TAI instead of UTC'
mode.

Leaving aside the leap table issue for the moment, there's a more
fundamental problem.  You cannot possibly compute correct answers for
times that are in the future, even a little ways in the future.  What
if time1 is June 30, 2006 23:59:58 and time2 is July 1, 2006 00:00:01.
While neither of these seconds are ambiguous, no one on the planet can
say today, with certainty, what the answer will be.  We have to wait
until early January when IERS issues the next Bulletin C.  You cannot
know today if the right answer is 2, 3 or 4.  If there's a negative
leap second at the end of June 30, then the answer is 2, if there's no
leap second the answer is 3, if there is a positive leap second, the
answer is 4.  One can only predict what might happen.  Until 6 months
before the leap second, no one knows what the schedule will be.

Have I mentioned my extreme and abiding love for leap seconds lately?
Now you know why :-)

Warner