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

["Kyzer Davis (kydavis)" <[e-mail]>]

> 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?

That is correct.

-----Original Message-----
From: Uuidrev <[e-mail]> On Behalf Of gutsier-guild-0m=[e-mail]
Sent: Friday, April 26, 2024 11:47 AM
To: [e-mail]
Subject: [Uuidrev] Potentially ambiguous - must UUIDv7 timestamp exclude leap seconds?

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
-- 
Uuidrev mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/uuidrev