Subject: [Cbor] draft-bormann-cbor-time-tag: POSIX and UTC are not the same

From: Emile Cormier <[email-masked]>
Date: Fri, 2 Apr 2021 23:00:19 -0300

In draft-bormann-cbor-time-tag (tags 1001-1003), UTC and POSIX are
confounded together under the same value of 0, under section 3.4. Key -1:
Time Scale.

UTC and POSIX are not the same! Per https://en.wikipedia.org/wiki/Unix_time:

... leap seconds are ignored, 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. Due to this treatment Unix time is not a true representation
> of UTC.
>

This is reinforced by the fact that C++ has distinct clocks for system time
and UTC:

https://en.cppreference.com/w/cpp/chrono/system_clock
https://en.cppreference.com/w/cpp/chrono/utc_clock

There should therefore be distinct values for POSIX and UTC.

Cheers,
Emile Cormier

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Apr 2021 09:34:11 +0200

On 3. Apr 2021, at 04:00, Emile Cormier <[email-masked]> wrote:
> 
> In draft-bormann-cbor-time-tag (tags 1001-1003), UTC and POSIX are confounded together under the same value of 0, under section 3.4. Key -1: Time Scale.
> 
> UTC and POSIX are not the same! Per https://en.wikipedia.org/wiki/Unix_time <https://en.wikipedia.org/wiki/Unix_time>:
> 
> ... leap seconds are ignored, 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. Due to this treatment Unix time is not a true representation of UTC.

Well, that text is slightly confused, as it is a true representation of UTC, except it can’t represent the 27 leap seconds we have had so far or any of the future ones.

> This is reinforced by the fact that C++ has distinct clocks for system time and UTC:
> 
> https://en.cppreference.com/w/cpp/chrono/system_clock <https://en.cppreference.com/w/cpp/chrono/system_clock>
> https://en.cppreference.com/w/cpp/chrono/utc_clock <https://en.cppreference.com/w/cpp/chrono/utc_clock>
> 

POSIX and UTC (and thus NTP) are shifted by leap seconds (which is sometimes called “ignoring leap seconds”, a term that should never be used; cppreference says “not counting leap seconds”, which means that you have to be aware of leap seconds to actively not count them).

TAI, GPS are true monotonic time scales.  Leap seconds have no influence on them (what cppreference calls “including leap seconds”).
As C++ utc_clock "includes leap seconds”, it appears to be a TAI referenced time scale (with a constant offset of 10 seconds from TAI).

I’m sorry, I didn’t invent this, I’m just the messenger :-)

Maybe adding an appendix on platform time representations would be worth it…
(We could also add more lines to figure 1, pointing out that C++ utc_clock is TAI minus 10 seconds.)

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 3 Apr 2021 10:03:19 +0200

+1 on adding some references and expositional text in an Appendix. While 
this document most certainly is also "only the message of the 
messenger", the underlying principles result in confusion, occasionally. 
I think it is a good idea to mitigate some of these occasions, pro-actively.

On 03.04.21 09:34, Carsten Bormann wrote:
> On 3. Apr 2021, at 04:00, Emile Cormier <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>> confounded together under the same value of 0, under section 3.4. Key 
>> -1: Time Scale.
>>
>>     ... leap seconds are ignored, 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. Due to this treatment Unix time
>>     is not a true representation of UTC.
> 
> Well, that text is slightly confused, as it is a true representation of 
> UTC, except it can’t represent the 27 leap seconds we have had so far or 
> any of the future ones.
> 
> POSIX and UTC (and thus NTP) are shifted by leap seconds (which is 
> sometimes called “ignoring leap seconds”, a term that should never be 
> used; cppreference says “not counting leap seconds”, which means that 
> you have to be aware of leap seconds to actively not count them).
> 
> TAI, GPS are true monotonic time scales.  Leap seconds have no influence 
> on them (what cppreference calls “including leap seconds”).
> As C++ utc_clock "includes leap seconds”, it appears to be a TAI 
> referenced time scale (with a constant offset of 10 seconds from TAI).
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Emile Cormier <[email-masked]>
Date: Sat, 3 Apr 2021 16:16:13 -0300

> referenced time scale (with a constant offset of 10 seconds from TAI).
Ah yes, the C++ utc_clock having a constant offset from TAI makes sense to
me now. This was the piece of the puzzle that my brain was missing. :-)

The C++ tai_clock ticks do indeed have a constant 10 second offset from
utc_clock ticks (ignoring epoch starting moments) as shown here:
https://github.com/HowardHinnant/date/blob/77bd6b92a4f7f6a1bbbc44952e6502a3448376b0/include/date/tz.h#L2084

Note that HowardHinnant/date was the incubator project that lead to the
enhanced date/time facilities in C++20.

Thank you bearing with me as I grappled to understand this.