[LEAPSECS] Common Calendar Time (CCT) -Brooks Harris

Joseph Gwinn joegwinn at comcast.net
Sun Jan 19 14:06:08 EST 2014


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


More information about the LEAPSECS mailing list