Re: [dtn] DTN time and RFC8877

[Brian Sipos <[e-mail]>]

Scott,
Your last revised text (in that email) is okay, except that I think it's best to avoid "unix time" or "unix epoch". Both "UTC" and "unix time" have a lot of baggage beyond using them as instant-of-time epoch references. And implementations of unix time seem to do all kinds of funny things that're not strictly in the specs.

Carsten,
The statement "... is not affected by leap seconds." is specifically the recommended language of RFC 8877 for describing this situation. DTN time uses a specific epoch instant as a zero reference and then uses TAI/UTC rate-of-time as its unit scale.
________________________________
From: Burleigh, Scott C (US 312B) <[e-mail]>
Sent: Friday, December 4, 2020 12:23
To: Brian Sipos <[e-mail]>; Carsten Bormann <[e-mail]>; R. Atkinson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: [dtn] DTN time and RFC8877


Brian, I think it’s actually not all that unusual: it’s exactly the way the time() system call is defined on the time(2) man page.  Unix calendar time is a simple count of seconds, just as TAI is, and the starting point of the count is a moment in time that we commonly identify as a time value on the UTC time scale.



It's true that TAI and UTC both advance at the same rate, one second per second, but the offset between TAI and UTC changes as new leap second adjustments are made in UTC: as each leap second is declared, the offset between TAI and UTC increases by 1 second – TAI advances by 1 second and UTC does not.  In my proposed revised text I said “DTN time is not affected by leap seconds.”  Does that address your concern?



Scott



From: dtn <[e-mail]> On Behalf Of Brian Sipos
Sent: Friday, December 4, 2020 9:10 AM
To: Carsten Bormann <[e-mail]>; R. Atkinson <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877



Scott,

I think the current statement is fine, it's just unusual to mix UTC-the-datum with TAI-the-lack-of-leap-seconds.

Because TAI and UTC only differ by a time-varying offset [1] but use the same rate, these two are identical statements:

  1.  "time elapsed since the start of the year 2000 on the Coordinated Universal Time (UTC) scale" which is what BPbis currently states.
  2.  "time elapsed since 32 seconds after the start of the year 2000 on the TAI scale" which accounts for the TAI-UTC leap second difference of 32 on 1 Jan 2000.

In either case, a statement such as the RFC8877 phrasing of "DTN Time is not affected by leap seconds." would add clarity to the situation without affecting the current agreed requirement text.



[1] https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fcdf.gsfc.nasa.gov%2Fhtml%2FCDFLeapSeconds.txt__%3B!!PvBDto6Hs4WbVuu7!au7pNhZH89rogLdZXrVRil2SNQj43GU3wk2GEVPxFbfnbJc0enzoIwG6JJkLTO6LGLz7VB40fAU%24&data=04%7C01%7CBSipos%40rkf-eng.com%7C34669fd5ab7740e52fb108d898794261%7C4ed8b15b911f42bc8524d89148858535%7C1%7C1%7C637426993859020246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=286lwpqaYG0s9nlF9KZWHdgUWrs2CFPxa0RnxP9P8zA%3D&reserved=0>

________________________________

From: Carsten Bormann <[e-mail]<mailto:[e-mail]>>
Sent: Friday, December 4, 2020 10:40
To: R. Atkinson <[e-mail]<mailto:[e-mail]>>
Cc: Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dtn] DTN time and RFC8877



On 2020-12-04, at 15:52, R. Atkinson <[e-mail]<mailto:[e-mail]>> wrote:
>
> (or specify that they are ignored).

You can’t say just that, because there are two ways to handle “ignoring” leap seconds, and when you say they are “ignored”, you don’t say which one.

(One way of “ignoring" leap seconds is to stay in TAI, which has no concept of leap seconds.
The other way is actually being cognizant of them and doing work to “ignore” them, i.e., reset the clock after each of them.  This is what UTC does to be able to “ignore” leap seconds.)

Grüße, Carsten