Date: Fri, 21 Oct 2005 09:32:34 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: bde@zeta.org.au Cc: cvs-src@freebsd.org, phk@phk.freebsd.dk, src-committers@freebsd.org, andre@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c Message-ID: <20051021.093234.116607170.imp@bsdimp.com> In-Reply-To: <20051021210822.E4739@delplex.bde.org> References: <20051021011035.T1945@delplex.bde.org> <20051020.121318.117917917.imp@bsdimp.com> <20051021210822.E4739@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20051021210822.E4739@delplex.bde.org>
Bruce Evans <bde@zeta.org.au> writes:
: Complain to wollman if this file is not updated. :-)
I can't complain to Wollman if I have a system that's at a customer
site that's been running for a while before the leap second is
announced. Such systems need a way to get and keep a table.
: This is not a problem for times returned by clock_gettime(), since those
: times are in the past.
:
: 64-bit time_t's and/or ints also permit asking the time library to do
: impossible predictions.
It is a problem. If I boot a system today, the authors of the
software still cannot know the example that I gave. Since there's no
leap second table by default, the system may get the answer wrong.
That's what is so evil about leap seconds. You can't plan more than 6
months into the future.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051021.093234.116607170.imp>