On Thu, Oct 31, 2024 at 9:53 PM Andrey M. Borodin <x4...@yandex-team.ru> wrote: > > > > > On 1 Nov 2024, at 03:00, Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > Therefore, if the > > system clock moves backward due to NTP, we cannot guarantee > > monotonicity and sortability. Is that right? > > Not exactly. Monotonicity is ensured for a given backend. We make sure that > timestamp is advanced at least for ~250ns forward on each UUID generation. 60 > bits of time are unique and ascending for a given backend. >
Thank you for your explanation. I now understand this code guarantees the monotonicity: +/* minimum amount of ns that guarantees step of increased_clock_precision */ +#define SUB_MILLISECOND_STEP (1000000/4096 + 1) + ns = get_real_time_ns(); + if (previous_ns + SUB_MILLISECOND_STEP >= ns) + ns = previous_ns + SUB_MILLISECOND_STEP; + previous_ns = ns; I think that one of the most important parts in UUIDv7 implementation is which method (1, 2, or 3 described in RFC 9562) we use to guarantee the monotonicity. The current patch employs method 3 with the assumption that 12 bits of sub-millisecond information is available on most of the systems we support. However, as far as I tested, on MacOS, values returned by clock_gettime(CLOCK_REALTIME) are only microsecond precision, meaning that we could waste some randomness. Has this point been considered? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
