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

Carsten Bormann <> Sat, 03 April 2021 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D5263A1125 for <>; Sat, 3 Apr 2021 00:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eHiT7uEW0PvA for <>; Sat, 3 Apr 2021 00:34:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29D6F3A1123 for <>; Sat, 3 Apr 2021 00:34:14 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FC7w42XF6zyPY; Sat, 3 Apr 2021 09:34:12 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_076C62BD-F6E1-40F7-8341-AD9BBA51E324"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sat, 03 Apr 2021 09:34:11 +0200
Message-Id: <>
References: <>
To: Emile Cormier <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Cbor] draft-bormann-cbor-time-tag: POSIX and UTC are not the same
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Apr 2021 07:34:19 -0000

On 3. Apr 2021, at 04:00, Emile Cormier <> 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 <>:
> ... 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:
> <>
> <>
> There should therefore be distinct values for POSIX and UTC.

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