[Uuidrev] Potentially ambiguous - must UUIDv7 timestamp exclude leap seconds?

gutsier-guild-0m@icloud.com Fri, 26 April 2024 15:47 UTC

Return-Path: <gutsier-guild-0m@icloud.com>
X-Original-To: uuidrev@ietfa.amsl.com
Delivered-To: uuidrev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05E1C15154A for <uuidrev@ietfa.amsl.com>; Fri, 26 Apr 2024 08:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.016
X-Spam-Level:
X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.777, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GortHKUz67Jj for <uuidrev@ietfa.amsl.com>; Fri, 26 Apr 2024 08:47:29 -0700 (PDT)
Received: from qs51p00im-qukt01072301.me.com (qs51p00im-qukt01072301.me.com [17.57.155.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BE4C151087 for <uuidrev@ietf.org>; Fri, 26 Apr 2024 08:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1714146449; bh=6pArKlfD1gZ7MxauB0BPU6agdbPChlT1+5vY9qCyFrw=; h=from:Content-Type:Mime-Version:Subject:Message-Id:Date:to; b=ZxbjiYUcMowWcZchtEVPEm4Eyoy0Nk7iWtDODDG0mQHkvoBNIERAvoGHaBhYnXrkp 69212Jq4x2xhwEm6Xyo1GrAV9mxII48eXB/9WoZDS9ThlE2e43veg91S3J/WnHI+ij 076lisecfTQ/KwkA9rK0Z0bGXXKMWvh0tsshcfe+H1SHj5S2x7LD9ZrBOWc5WcYrQv pjgkb19Hqdism1UgH5a+WiJGISMmF7ieoB7HCFU4pjGayC9/rvpDXjFbb+NIGc3drC oWsZ8pS31xCeSik8bpeQ28nS3DskpClGmdm4LbG60ieKRW8oJs9K9DggcCGrK+By12 HfSwGlR6qxayw==
Received: from smtpclient.apple (qs51p00im-dlb-asmtp-mailmevip.me.com [17.57.155.28]) by qs51p00im-qukt01072301.me.com (Postfix) with ESMTPSA id 5BCB125402A9 for <uuidrev_at_ietf_org_f5802e639em0ce_f6481948@icloud.com>; Fri, 26 Apr 2024 15:47:28 +0000 (UTC)
from: gutsier-guild-0m@icloud.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Message-Id: <015342E4-BA0D-495F-B846-279734B4EFD8@icloud.com>
Date: Fri, 26 Apr 2024 17:47:15 +0200
to: uuidrev@ietf.org
X-Mailer: Apple Mail (2.3774.500.171.1.1)
X-CLX-Shades: None
X-CLX-UShades: None
X-CLX-Score: 74
X-CLX-UnSpecialScore: None
X-CLX-Spam: false
X-MANTSH: 1TFkXHR4RCllEF2VDWW5kaEtSTxMTEQpZTRdkRURPEQpZSRcHGRpxGwYHHBp3Bhs aHgYaBhoGGgYacRoQGncGGgYaBhoGGgYaBhpxGhAadwYaEQpZXhdobnkRCkNOF2JmRVNNewd1G GJtRXh4H3VeGBJZfgdzTG5iYmFQWEYbEQpYXBcZBBoEHxoFGxoEGxwYBBkaBBgSEBseGh8aEQp eWRdOc3JvWBEKTFoXaENra2sRCkVZF29raxEKQ1oXGxoTBBsaHgQfHgQYHxEKQl4XGxEKRF4XG BEKXk4XGxEKQkUXaxt/Em9gfkBlAWARCkJOF2tFGlJQHkNcWVxoEQpCTBdrG38Sb2B+QGUBYBE KQmwXaxt/Em9gfkBlAWARCkJAF3oFBXscXlJyehpwEQpCWBdkTVMBYnNNXxsBUBEKRUMXGxEKc GgXehhdfEUTXWNBGnkQBxkaEQpwaBdkR0JDQB5YTmkSehAHGRoRCnBoF2tlaUlmQmwZX2dYEAc ZGhEKcGgXbnB9GhwaWWVjUkcQBxkaEQpwaBdrHUR8QHMTHnAYfhAHGRoRCnBoF2lyBXpOGG4cH GNEEAcZGhEKcGgXaxpGQH1oGxpHcHsQBxkaEQpwaBdjelxAblBBT2tFSxAHGRoRCnBMF2sdWk9 PbQUbSwUeEAcZGhEKbX4XGhEKWE0XSxE=
X-Proofpoint-GUID: HLoygQ-_2HGoRR5_t28sT-YfDHHKzrl1
X-Proofpoint-ORIG-GUID: HLoygQ-_2HGoRR5_t28sT-YfDHHKzrl1
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-04-26_13,2024-04-26_02,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 malwarescore=0 clxscore=74 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2404260107
Archived-At: <https://mailarchive.ietf.org/arch/msg/uuidrev/asdXv9EbgY56drbWALVW4eCaLM8>
X-Mailman-Approved-At: Fri, 26 Apr 2024 12:27:14 -0700
Subject: [Uuidrev] Potentially ambiguous - must UUIDv7 timestamp exclude leap seconds?
X-BeenThere: uuidrev@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revise Universally Unique Identifier Definitions <uuidrev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uuidrev>, <mailto:uuidrev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uuidrev/>
List-Post: <mailto:uuidrev@ietf.org>
List-Help: <mailto:uuidrev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uuidrev>, <mailto:uuidrev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2024 15:48:43 -0000

Looking at revision 14 of the draft spec, Section 5.7 (UUID Version 7) says:

> UUID version 7 features a time-ordered value field derived from the widely implemented and well known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded.

However, Section 6.1 (Timestamp Considerations) says:

> For example, if it is possible for the system clock to move backward due to either manual adjustment or corrections from a time synchronization protocol, implementations need to determine how to handle such cases.

and

> Implementations MAY alter the actual timestamp. Some examples include security considerations around providing a real clock value within a UUID, to correct inaccurate clocks, to handle leap seconds, or instead of dividing a number of microseconds by 1000 to obtain a millisecond value; dividing by 1024 (or some other value) for performance reasons. This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time.

It isn’t clear to me when reading this whether an implementation of UUIDv7 must exclude leap seconds -- the only true requirement seems to be that they are monotonic. The way I read 6.1 is that it gives us the freedom to handle leap seconds however we like, so long as we retain that property. Is that correct?

Thanks,

Karl