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 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>
Sent: Friday, November 8, 2019 6:33 AM
To: lloyd.w...@yahoo.co.uk
Cc: Magnus Westerlund <magnus.westerl...@ericsson.com>; last-c...@ietf.org; 
gen-art@ietf.org; draft-ietf-dtn-bpbis....@ietf.org; 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

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



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to