MIME-Version: 1.0
From: Faye Amacker <faye.github@gmail.com>
Date: Sun, 10 Aug 2025 17:47:43 -0500
Message-ID: 
 <CA+qCGhu55TzJRh6X5DMZ9n4e6basOwOBbstgo1QDsvLzF2nLzg@mail.gmail.com>
To: cbor@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ff3a50063c0a98b0"
Message-ID-Hash: WK57XPPOJZTUCRH6NTOWM3BFGUJ5FLKZ
Precedence: list
Subject: =?utf-8?q?=5BCbor=5D_Tag_for_Nanoseconds_Since_Unix_Epoch_in_Int64_Range?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/cbor/BFMhoPkeq8ibKg-4JRwQ78FaGC4>

--000000000000ff3a50063c0a98b0
Content-Type: text/plain; charset="UTF-8"

Hello,

I maintain a generic CBOR codec[1] and collected some feedback/issues that
might be resolved by using a new CBOR tag (if approved).

Currently, CBOR can encode time with nanoseconds as:
- CBOR tag 0 with text string that is ~30 bytes long (vs ~8 bytes in other
formats)
- CBOR tag 1 with a floating point value that can be lossy (e.g., fails
round trip in fuzz tests and serialization format comparison tests)

A simple way to resolve these is by using a CBOR tag for nanoseconds
elapsed since Unix epoch as an integer in the range -2^63..2^63-1
inclusive.  This allows efficient and lossless encoding of nanoseconds
that can represent time from Sept. 1677 to April 2262.  The tag can be
applied to an unsigned integer (major type 0) or a negative integer (major
type 1).

I wrote a draft proposal[2] with more details. It includes "Rationale"
section with alternatives considered and an "Examples" section that
mentions considerations for negative values.

Thoughts?

[1] https://github.com/fxamacker/cbor
[2]
https://github.com/fxamacker/CBOR-Tag-Specs/blob/master/TimeUnixNanoInt64.md

--000000000000ff3a50063c0a98b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div><br></div><div>I maintain a generic =
CBOR codec[1] and collected some feedback/issues that might be resolved by =
using a new CBOR tag (if approved).<br></div><div><div><br>Currently, CBOR =
can encode time with nanoseconds as:<br>- CBOR tag 0 with text string that =
is ~30 bytes long (vs ~8 bytes in other formats)<br>- CBOR tag 1 with a flo=
ating point value that can be lossy (e.g., fails round trip in fuzz tests a=
nd serialization format comparison tests)<br></div><div><br></div></div><di=
v>A simple way to resolve these is by using a CBOR tag for nanoseconds elap=
sed since Unix epoch as an integer in the range=20
-2^63..2^63-1 inclusive.=C2=A0 This allows efficient and lossless encoding =
of
 nanoseconds that=C2=A0can represent time from Sept. 1677 to April 2262.=C2=
=A0 The tag can be applied to an unsigned integer (major type 0) or a negat=
ive integer (major type 1).</div><div><br></div><div>I wrote a draft propos=
al[2] with more details. It includes &quot;Rationale&quot; section with alt=
ernatives considered and an &quot;Examples&quot; section that mentions cons=
iderations for negative values.</div><div><br></div><div>Thoughts?</div><di=
v><br></div><div>[1] <a href=3D"https://github.com/fxamacker/cbor">https://=
github.com/fxamacker/cbor</a></div><div>[2]=C2=A0<a href=3D"https://github.=
com/fxamacker/CBOR-Tag-Specs/blob/master/TimeUnixNanoInt64.md">https://gith=
ub.com/fxamacker/CBOR-Tag-Specs/blob/master/TimeUnixNanoInt64.md</a></div><=
div><br><br></div></div>

--000000000000ff3a50063c0a98b0--