Unix time != the Posix time API. One is a time scale; the other is the interface to obtain potentially many different time scales.
I dove into these issues here: draft-touch-time Joe > On Nov 8, 2019, at 7:34 AM, 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] > <https://en.wikipedia.org/wiki/Unix_time#cite_note-1> seconds since the > Epoch,[2] > <https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> > or UNIX Epoch time[3] <https://en.wikipedia.org/wiki/Unix_time#cite_note-3>) > is a system for describing a point in time > <https://en.wikipedia.org/wiki/Timestamp>. It is the number of seconds > <https://en.wikipedia.org/wiki/Second> that have elapsed since the Unix > epoch, that is the time 00:00:00 UTC > <https://en.wikipedia.org/wiki/Coordinated_Universal_Time> on 1 January 1970, > minus leap seconds <https://en.wikipedia.org/wiki/Leap_second>. Leap seconds > are ignored,[4] > <https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-rationale-4.16-4> > with a leap second having the same Unix time as the second before it, and > every day is treated as if it contains exactly 86400 seconds.[2] > <https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> > Due to this treatment Unix time is not a true representation of UTC. > > Now, of course, this is Wikipedia, which everyone knows to be useless and > unreliable. But the summary is at least concise and clear, and in this > particular case it is supported by several source documents, noted at the > bottom of the article. > > 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.” > > Going back a bit, page 166 of > https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf > <https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf> > Dennis and Ritchie (who ought to know) say “Time returns the time since > 00:00:00 GMT, Jan. 1, 1970, measured in seconds.” > > 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. > > Scott > > From: Stewart Bryant <stewart.bry...@gmail.com > <mailto:stewart.bry...@gmail.com>> > Sent: Friday, November 8, 2019 6:33 AM > To: lloyd.w...@yahoo.co.uk <mailto:lloyd.w...@yahoo.co.uk> > Cc: Magnus Westerlund <magnus.westerl...@ericsson.com > <mailto:magnus.westerl...@ericsson.com>>; last-c...@ietf.org > <mailto:last-c...@ietf.org>; gen-art@ietf.org <mailto:gen-art@ietf.org>; > draft-ietf-dtn-bpbis....@ietf.org <mailto:draft-ietf-dtn-bpbis....@ietf.org>; > d...@ietf.org <mailto:d...@ietf.org> > Subject: [EXTERNAL] Re: [Last-Call] Genart last call review of > draft-ietf-dtn-bpbis-17 > > > > > On 8 Nov 2019, at 13:03, lloyd.w...@yahoo.co.uk > <mailto:lloyd.w...@yahoo.co.uk> wrote: > > http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf > > <http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf> > > The critical text in that paper is: > > "The Bundle Protocol uses Coordinated Universal Time (UTC), where leap > seconds are added at irregular, unpredictable, intervals to reflect slowing > of the Earth’s rotation. For nodes ‘in the field’ for a long time (decades), > some way of communicating newly-decided UTC leap seconds will be required to > prevent clock drift over long time scales that would eventually lead to > bundles expiring before delivery. This is most likely to be a significant > issue for real-time traffic with very short bundle lifetimes." > That says that leap-seconds need to be transmitted to the remote site, but > the ID does not say anything about that, indeed it silently implies that this > is handled. > The draft text says > Like TAI, Unix epoch time > is simply a count of seconds elapsed since a standard epoch. Unlike > TAI, the current value of Unix epoch time is provided by virtually > all operating systems on which BP is likely to run. > > Which is not quite right. The TAI is a continuous count of the number of > seconds since the epoch. The UNIX tine is the continuous count + leap seconds > since the epoch. Unix knows how many leap seconds have happened by a > background process and adds them in, but for that to work it has to have a > method of knowing the current leap second state. BTW leap seconds can be > removed as well as added. > > - Stewart > > > > -- > last-call mailing list > last-c...@ietf.org <mailto:last-c...@ietf.org> > https://www.ietf.org/mailman/listinfo/last-call > <https://www.ietf.org/mailman/listinfo/last-call>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
