On Sat, 18 Jan 2014 23:10:41 -0800, Brooks Harris wrote: > On 2014-01-18 09:39 AM, Zefram wrote: >> Joseph Gwinn wrote: >>> No. If your poke around into how time is used, you will discover that >>> what is stored is the count of seconds since the Epoch. Broken-down >>> time is used only when there is a human to be humored. >> >> Sure, scalar time_t values are used underneath, and I didn't say >> otherwise. That's what time_t is for. The kernel even increments the >> time_t clock, most of the time, as if it's a linear count of seconds, >> which is how it behaves on the small scale outside the immediate >> vicinity of leap seconds. But a kernel that knows about leap seconds >> then introduces a discontinuity in the scalar value, somewhere near each >> leap, to maintain the scalar<->UTC relationship. > > Yes, two related issues - > > 1) There's no specification how the kernel should behave. > 2) The POSIX API has its shortcomings, as you note, and these are > tangled with the kernel's behavior.
It's true that POSIX governs APIs (application-program interfaces), and does not govern kernel implementation details. This is as intended. > On Windows, in c/c++, the POSIX API is implemented as a sub-system > which in turn calls proprietary Windows time APIs, like > ::GetSystemTime(), ::GetFileTime() and related. Divining exactly how > those are behaving is a challenge. Some parts of the POSIX API are > just not implemented, and some versions of MSVC c/c++ implement > non-standard 64-bit versions. > > Also, not all versions of POSIX are equally good. I've found smoking > gun bugs in some implementations of gmtime() and related. Yes. > Meantime, as you note in > http://www.fysh.org/~zefram/time/prog_on_time_scales.pdf, > Disseminating Leap Schedule to Machines, is a missing link in the > whole UTC world is a well defined and reliable method of obtaining > the proper metadata (Leap Seconds table, announce signals, etc). This > needs to be addressed somehow by somebody. I didn't write the referenced article. I just scanned it, but don't see how is solves the problems POSIX tries to solve. And there are plenty of articles on how time ought to be determined and represented - the matter is still very much in play with respect to UTC and the possible dropping of leap seconds. This may or may not be settled during my career. >>> POSIX time is defined without reference to NTP, > >> Indeed. The two definitions are separate, but match in most of their >> design features. > > POSIX count "steps back" on Leap Second insertion. NTP count > "freezes" on Leap Second insertion. Either way there's an ambiguity, > so that's one design feature they share :-). > > NTP *does* refer to POSIX - Figure 4: Interesting Historic NTP Dates > refers to "First day UNIX" and locates it 63072000 seconds before > 1972-01-01T00:00:00Z (UTC). This helps solve one problem - when, > exactly, was the POSIX "the Epoch". Ok. I meant a normative reference, in the sense of coordinated standards. An interesting historical note isn't really coordination. Joe Gwinn _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
