On Nov 8, 2019, at 16:34, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@xxxxxxxxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
