Path: utzoo!mnetor!uunet!husc6!yale!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.bugs.4bsd Subject: Re: ctime(3) and leap seconds :-( Message-ID: <7061@brl-smoke.ARPA> Date: 13 Jan 88 05:25:35 GMT References: <604@PT.CS.CMU.EDU> <6976@brl-smoke.ARPA> <20532@amdahl.amdahl.com> <175@wundt.psy.vu.nl> <1964@rti.UUCP> <7040@brl-smoke.ARPA> <20700@amdahl.amdahl.com> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 98 Keywords: ctime, leap second, epoch In article <20700@amdahl.amdahl.com> chongo@amdahl.amdahl.com (Landon Curt Noll) writes: >POSIX does not say that a conforming machine MUST have the correct time! >What it does say is that given some specific time, it MUST produce the >same timestamp. Quoting IEEE Std 1003.1 Draft 12: The Epoch refers to the time at 0 hours, 0 minutes, 0 seconds, Coordinated Universal Time on January 1, 1970. The value "seconds since the Epoch" refers to the difference in seconds between the referenced time and the Epoch, not counting leap seconds. The time() function returns the value of time in seconds since the Epoch. [There are also specific extensions to the asctime() function that aren't relevant to the discussion.] I believe it pretty clearly specifies what time() must return. I would call that "the correct time" (expressed in seconds since the Epoch, with the wart of having to know how many leap seconds to leave out). By the way, It might be nice to specify that this is the intent of time(), without insisting on exactness, since not only are most systems not synchronized with standard time references, but also one never knows how long a system call will actually take to complete. ANSI X3.159-198x specifies that the localtime(), gmtime(), and ctime() functions convert the system time (what time() returns) into the usual fields (year, month, week, day, hour, minute, second, etc.). No surprises here. ---------- Mappings: genuine uniform time ---> genuine time since Epoch (by specification of when the Epoch is) genuine time since Epoch ---> Draft 12 "time since Epoch" (by omitting leap seconds) Draft 12 "time since Epoch" ---> system time (equivalence specified by Draft 12) system time ---> broken-down time (by gmtime() or localtime()) broken-down time ---> string at user interface (by asctime()) note: ctime = asctime(localtime) The two quantities of interest are the "system time" returned by time(), and the string seen at the user interface, which undoubtedly should correspond as closely as possible with the time of day on the wall clock. The above mappings are all invertible (except near leap seconds), so if a user-interface form of time is specified, as when the system administrator "sets the time", we can track backwards to determine what "system time" the operating system maintains. Chongo apparently wanted to make the fourth mapping arithmetically simpler, which is why leap secons are not visible to it. Unfortunately, when a leap second does occur, the user-interface time is supposed to exhibit a glitch, which it can only do if someone deliberately resets the system time to force the glitch. How much smoother it would be if the system clock did not need to be reset in order to keep the user-interface times tracking the official wall clocks. This could be accomplished by instead using the following mappings: genuine uniform time ---> genuine time since Epoch (by specification of when the Epoch is) genuine time since Epoch ---> system time (equivalence recommended instead of Draft 12's) system time ---> broken-down time (by gmtime() or localtime()) broken-down time ---> string at user interface (by asctime()) note: ctime = asctime(localtime) This may seem like a minor difference, but it has practical effects: It would leave the kernel clock runnning uniformly even across a leap second, and with a bit more work in gmtime()/localtime() the leap seconds can be allowed for and reported properly, as in the original "bug fix" that prompted this discussion. An added bonus is that the "seconds since the Epoch" would mean just that, which is more useful than the Draft 12 meaning, if one really does have a synchronized system clock and cares about absolute time references (for example, for event logging). Two things are needed to achieve this: Leap seconds need to be reinstated into "seconds since the Epoch" in IEEE Std 1003.1. tm_sec must be allowed to hold the value 60 for a leap second in ANSI X3.159-198x. (There really are 61 seconds in some minutes, just as there really are 29 days in some Februaries.) If we can get agreement on this, there may still be time to get this fixed before these standards are frozen.