[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
- [Uuidrev] [Errata Verified] RFC9562 (8288) RFC Errata System