Date: Tue, 3 Jan 2006 08:26:20 -0800 (PST) From: Jon Dama <jd@ugcs.caltech.edu> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Peter Jeremy <PeterJeremy@optushome.com.au>, current@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: FreeBSD handles leapsecond correctly Message-ID: <Pine.LNX.4.53.0601030809350.29738@lira.ugcs.caltech.edu> In-Reply-To: <83586.1136285992@critter.freebsd.dk> References: <83586.1136285992@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
I think you had the answer more clearly earlier. Computers display event times in UTC, but intervals are based on SI seconds (and now finer granuality). I might be crazy, but I understand stopwatch seconds after the epoch (SI) to be the fundamental unit of POSIX time. Days, Hours, Months, etc simply does not enter into the consideration except in the context of "formating functions" such as gmtime(), localtime(), mktime(), etc. Here I agree that POSIX is lying when it suggests you can get UTC time out without leapsecond tables, but this does not seem to be a very fundamental problem. difftime operates on stopwatch seconds after the epoch. It is quite informative to realize that time_t has sub-second granularity whereas struct tm have seconds as their smallest unit of time. Typically on any instrument, at least the least significant digit is considered approximate. Such will be the case in regards to the POSIX definition of time for some years into the future. So chill. If you just avoid discussing the translation of stopwatch seconds into minutes/hours/days the problem goes away and we can all chalk up that conversion of seconds into minutes/hours/days that we all learned in grade school as another poorly explained simplification and proceed to unlearn it from our minds.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.53.0601030809350.29738>