CBORbis defines an “Epoch-based Date/Time” here <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-09#section-3.4.3> making normative reference to Posix time with a brief discussion of leap seconds, positive and negative values and number of bits.
(I’m not familiar with draft-ietf-dtn-bpbis-xxm, just saw the time discussion and thought it might be of use) LL > On Nov 8, 2019, at 7:40 AM, Joe Touch <[email protected]> wrote: > > 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) >> <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> >> Sent: Friday, November 8, 2019 6:33 AM >> To: [email protected] <mailto:[email protected]> >> Cc: Magnus Westerlund <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]>; [email protected] <mailto:[email protected]>; >> [email protected] >> <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> Subject: [EXTERNAL] Re: [Last-Call] Genart last call review of >> draft-ietf-dtn-bpbis-17 >> >> >> >> >> On 8 Nov 2019, at 13:03, [email protected] >> <mailto:[email protected]> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/last-call >> <https://www.ietf.org/mailman/listinfo/last-call> > -- > last-call mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
