On Thu, 29 May 2025 18:30:59 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> 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. Latest update: - changed to millis + randomByte allocation implementation - updated method to take user provided timestamp - added API which delegates to method with current timestamp if no user input provided - validated user input (this is far from fool proof, but prevents negative time values and some other time formats) - updated method name to unixEpochTimeMillis - added a note with ref to rfc to make user aware of time format required for rfc compliance - added test coverage Updated benchmark: Benchmark Mode Cnt Score Error Units UUIDBenchmark.unixEpochTimeMillis avgt 25 138.076 ± 11.438 ns/op ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2115691663
