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

[Joseph Gwinn]

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