Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!mit-eddie!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.bugs.4bsd
Subject: Re: ctime(3) and leap seconds :-)
Keywords: ctime, leap second, epoch
Message-ID: <7040@brl-smoke.ARPA>
Date: 11 Jan 88 23:35:13 GMT
References: <604@PT.CS.CMU.EDU> <6976@brl-smoke.ARPA> <20532@amdahl.amdahl.com> <175@wundt.psy.vu.nl> <1964@rti.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29
Posted: Mon Jan 11 18:35:13 1988

In article <1964@rti.UUCP> trt@rti.UUCP (Thomas Truscott) writes:
>I SUGGEST THAT POSIX
>1. Encourage fixes for the leap-second and other problems of ctime()
>    and related programs.
>2. Document that application of such fixes is recommended.

I agree with Tom's analysis and recommendations.

Note that the "epoch" in practice is really whatever is obtained
by the inverse of ctime() built into the set-date command, whenever
a system administrator looks at the wall clock to set the system
time.  It isn't really 00:00:00, Jan 1, 1970, although it will
usually be close to it (unless the administrator is purposely
establishing a fake date for some reason, which occasionally is
useful).  No amount of standardization will change this fact of
life, so the definitions should make as much sense as possible.

I could accept having the POSIX standard permit implementations to
maintain a "reasonably close" approximation to whatever is defined.
Only sites with extremely good connections to a controlled time
reference have much chance of being within a tick of the
theoretically "correct" time setting anyway.  That would clearly
be demanding too much precision.

The most useful thing for ctime() to report would be something
very close to the wall-clock time at which the corresponding
time() function was invoked.  Whether the number of seconds since
some artifical epoch is exact or not is of no consequence to most
non-astronomical applications.