[Uuidrev] [Errata Verified] RFC9562 (8288)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 24 February 2025 21:35 UTC

Return-Path: <wwwrun@rfcpa.rfc-editor.org>
X-Original-To: uuidrev@mail2.ietf.org
Delivered-To: uuidrev@mail2.ietf.org
Received: from mail2.ietf.org (mail2 [166.84.6.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPSA id 154EE9C693; Mon, 24 Feb 2025 13:35:50 -0800 (PST)
Received: from rfcpa.rfc-editor.org (unknown [167.172.21.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 00A8C9C691; Mon, 24 Feb 2025 13:35:49 -0800 (PST)
Received: by rfcpa.rfc-editor.org (Postfix, from userid 461) id AF8B1259692; Mon, 24 Feb 2025 13:35:49 -0800 (PST)
To: nathanmcgarvey@gmail.com, kydavis@cisco.com, brad@peabody.io, pjl7@uw.edu
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20250224213549.AF8B1259692@rfcpa.rfc-editor.org>
Date: Mon, 24 Feb 2025 13:35:49 -0800
Message-ID-Hash: SYTFVSJE3GWM6C27HFZMYXR6FW2DWAG2
X-Message-ID-Hash: SYTFVSJE3GWM6C27HFZMYXR6FW2DWAG2
X-MailFrom: wwwrun@rfcpa.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: orie@transmute.industries, iesg@ietf.org, uuidrev@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Uuidrev] [Errata Verified] RFC9562 (8288)
List-Id: Revise Universally Unique Identifier Definitions <uuidrev.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uuidrev/NVWRq_-HcpLLIMVP-HzHhfuG1w8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uuidrev>
List-Help: <mailto:uuidrev-request@ietf.org?subject=help>
List-Owner: <mailto:uuidrev-owner@ietf.org>
List-Post: <mailto:uuidrev@ietf.org>
List-Subscribe: <mailto:uuidrev-join@ietf.org>
List-Unsubscribe: <mailto:uuidrev-leave@ietf.org>

The following errata report has been verified for RFC9562,
"Universally Unique IDentifiers (UUIDs)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8288

--------------------------------------
Status: Verified
Type: Technical

Reported by: Nathan McGarvey <nathanmcgarvey@gmail.com>
Date Reported: 2025-02-08
Verified by: Orie Steele (IESG)

Section: 6.1

Original Text
-------------
   Length:
      The length of a given timestamp directly impacts how many
      timestamp ticks can be contained in a UUID before the maximum
      value for the timestamp field is reached.  Take care to ensure
      that the proper length is selected for a given timestamp.  UUIDv1
      and UUIDv6 utilize a 60-bit timestamp valid until 5623 AD; UUIDv7
      features a 48-bit timestamp valid until the year 10889 AD.

Corrected Text
--------------
   Length:
      The length of a given timestamp directly impacts how many
      timestamp ticks can be contained in a UUID before the maximum
      value for the timestamp field is reached.  Take care to ensure
      that the proper length is selected for a given timestamp.  UUIDv1
      and UUIDv6 utilize a 60-bit timestamp valid until 5236 AD; UUIDv7
      features a 48-bit timestamp valid until the year 10889 AD.

Notes
-----
I believe the error is the result of a bad calculation that used the Unix epoch as the zero-date instead of the Gregorian calendar's 1582 zero-date. I've seen online references to the following [incorrect] calculation for determining the UUIDv1 maximum date: (2^60 / 10^7 / 60 / 60 / 24 / 365.25 + 1970) = 5623.38778807. Source: https://github.com/uuid6/uuid6-ietf-draft/issues/23#issuecomment-898866487

That is: (bitsOfTimeData / 100 nanoseconds / secondsPerMin / minutesPerHour / hoursPerDay / daysPerYear + unixEpochYear). However, the max date for v1 and v6 is based, not on the Unix epoch year, but on the year 1582 (Ref: section 5.1).


The same calculation, but using 1582 as the trailing year added, is 5235.38778807.




Doing manual math approximation:

60 bits = 2^60 = 1152921504606846976 one-hundred-nano-second-intervals
1152921504606846976 * 100 = 115292150460684697600 nanoseconds

115292150460684697600 nanoseconds / 31557600000000000 nanosecondPerYear (365.25 daysPerYear assumed) =~ 3653.3878 years.

Date math: 1582.7890 + 3653.3878 years = 5236.1768 =~ March of 5236




Exact date math spot checking using a couple of programming languages calculators:

Go:

package main

import (
	"fmt"
	"time"
)

func main() {
	t := time.Date(1582, 10, 15, 0, 0, 0, 0, time.UTC)
	for _ = range 100 {
		t = t.Add(1152921504606846976)
	}
	fmt.Println(t)
}


Output: 5236-03-31 21:21:00.6846976 +0000 UTC



Python:

from datetime import datetime, timedelta, timezone

start_date = datetime(1582, 10, 15, tzinfo=timezone.utc)

nanoseconds = 115292150460684697600
seconds = nanoseconds // 1_000_000_000  # Convert to seconds
remaining_nanoseconds = nanoseconds % 1_000_000_000
microseconds = remaining_nanoseconds // 1000  # Convert remaining to microseconds

delta = timedelta(seconds=seconds, microseconds=microseconds)

result_date = start_date + delta

print(result_date)


Output: 5236-03-31 21:21:00.684697+00:00



Javascript:

const startDate = new Date(Date.UTC(1582, 9, 15)); // Month is 0-based in JS
const nanoseconds = BigInt('115292150460684697600');

const milliseconds = Number(nanoseconds / BigInt(1_000_000));

const resultDate = new Date(startDate.getTime() + milliseconds);

console.log(resultDate.toUTCString());


Output: Mon, 31 Mar 5236 21:21:00 GMT

--------------------------------------
RFC9562 (draft-ietf-uuidrev-rfc4122bis-14)
--------------------------------------
Title               : Universally Unique IDentifiers (UUIDs)
Publication Date    : May 2024
Author(s)           : K. Davis, B. Peabody, P. Leach
Category            : PROPOSED STANDARD
Source              : Revise Universally Unique Identifier Definitions
Stream              : IETF
Verifying Party     : IESG