On Nov 8, 2019, at 16:34, Burleigh, Scott C (US 312B) 
<scott.c.burleigh=40jpl.nasa....@dmarc.ietf.org> wrote:
> I disagree.  From Wikipedia:
> Unix time (also known as Epoch time, POSIX time,[1] seconds since the 
> Epoch,[2] or UNIX Epoch time[3]) is a system for describing a point in time. 
> It is the number of seconds that have elapsed since the Unix epoch, that is 
> the time 00:00:00 UTC on 1 January 1970, minus leap seconds. Leap seconds are 
> ignored,[4] 

There is a problem with this phrase.
You cannot “ignore” leap seconds if you want Posix time.
To the contrary, you need to subtract every single one of them from the number 
of seconds you count from the Epoch.

Leap seconds are actively *not counted*, not “ignored”.
Of course, if you think “ignore” means “not count”, you will think the sentence 
makes sense.
There are time scales that don’t know about leap seconds, such as TAI or GPS 
Posix time does know about leap seconds, it needs them to be mostly compatible 
with civil time (UTC).

(*) The GPS signal indicates the accumulated number of leap seconds since GPS 
epoch *along with* the monotonic time in GPS time scale (that “ignores” the 
fact that there are leap seconds).

Sorry for overstressing the semantics here, but from teaching I know that half 
of the people understand “ignore” as “do not take any notice of”, as TAI does, 
and only the other half understands that you mean “do not count” as an explicit 
act of “ignoring”, as in Posix time.

> For example, “The Open Group Base Specifications Issue 7, Rationale: Base 
> Definitions”, section A.4 (General Concepts) says “Coordinated Universal Time 
> (UTC) includes leap seconds. However, in POSIX time (seconds since the 
> Epoch), leap seconds are ignored (not applied) to provide an easy and 
> compatible method of computing time differences.”

“Not applied” has the same problem, maybe slightly less so.

You “apply” leap seconds to Posix time by *not counting* them.

> I am happy to agree that an operating system’s implementation of the time() 
> function may typically obtain accurate UTC time (from GPS or NTP) and 
> subtract the leap seconds out of that value to obtain Epoch time, and in this 
> sense the implementation of the time() function is typically dependent on 
> information about leap seconds.
> But that is an implementation expedient, which BP does not care about.  What 
> BP cares about is expressing time as a number of seconds that have elapsed 
> since the Epoch (minus an offset, the number of seconds elapsed from the 
> Epoch to midnight 1 January 2000 UTC).  The manner in which that value is 
> generated doesn’t matter to the protocol.

That is correct, but it means you can’t have a BP node that doesn’t know about 
leap seconds (either explicitly or by periodically resetting its clock to the 
Posix representation of civil time, which in many cases you do anyway because 
of clock drift).

Grüße, Carsten

Gen-art mailing list

Reply via email to