On Thu, 29 May 2025 17:05:23 GMT, kieran-farrell <d...@openjdk.org> wrote:
>> 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? RFC 9562 does not indicate any relation between the timestamp value and the "current" time. So yes, document it as the Unix Epoch, milliseconds since 1970. There could be plenty of use cases for creating a UUID from some other source of time, like the timestamp of a file or a time field in a database. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2114523897
