On Wed, 28 May 2025 20:57:15 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> The first 48 bits need to be from the unix epoch time stamp in ms only to >> remain complaint. If I understand correctly, to be able to guarantee that >> the nsBits are actually time orderable, System.nanoTime() would have to be >> pinned to a point where System.currentTimeMillis() increments by 1ms (which >> doesnt seem possible). Otherwise any offset could be at any arbitrary point >> in a given millisecond and nsBits would wrap around from that. >> >> I think the options are to either use the random only approach with ms >> precision or an guaranteed monotonic counter based approach and take the hit >> on performance. >> >> I agree with updating to "create" from "retrieve" on the first line comment >> and also with the method name change to avoid confusion with UUIDv1, however >> to either unixEpochTimeNanos() or unixEpochTimeMillis() or otherwise >> depending on which implementation we settle on. > > We don't have a reliable sub-microsecond source across platforms, so can only > be confident using random numbers for the low order bits. (and I don't expect > a higher resolution monotonic clock to be available anytime soon). > > Would the static factory method be more useful if it took the mstime as a > parameter? > That would allow the caller to pick the time source. For example, > ` UUID ts = UUID.timesteampUUID(System.currentTimeMillis());` > It would avoid locking into the System.currentTimeMillis() and allows the > application to create UUIDs for whatever time meets its needs. > > Adding a unixEpochTimeMillis() makes sense, re-assembling the time bits into > the ms time. In terms of using another clock it could open up possiblities of passing non complaint time formats to the method, but maybe thats something that could be mostly prevented with input validation and clear documentation i.e. “timestamp must be Unix time in milliseconds.” As far as I know all other standard Java methods that gives the current time in milliseconds ultimately delegates to System.currentTimeMillis(). Maybe there would be a use case in generating UUIDs by passing compliant timestamps for entries created in the past, like updating a database to use UUIDv7? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2114384770
