Address possible clock non-linearity or "pausing" due to leap seconds (or other expected timeline discontinuities)

[broofa]

We have discussed (at length) how important monotonicity is in timestamps. Specifically, the draft currently states:

Implementations SHOULD use the current timestamp from a reliable source to provide values that are time-ordered and continually increasing

However this may be at odds with Unix Time where leap-seconds are involved. For example, an uncompensated unix time clock may regress thusly:

NTP addresses this case by "pausing" the clock during a leap second so that the time remains monotonic, but even that is not without issue. For example, if the counter field width is selected to handle a certain maximum number of ids being generated every millisecond but the clock pauses for one or more seconds, the number of ids that occur during that interval may be 1000x more than expected, leading to a counter overflow.

I don't have text to propose at this time. 'Just noting this as an issue that we might want to address.

[peterbourgon]

Any time source which yields non-monotonic times doesn't satisfy the requirement:

Implementations SHOULD use the current timestamp from a reliable source to provide values that are time-ordered and continually increasing

So I reckon this is out-of-scope?

[kyzer-davis]

@peterbourgon, the point is just calling out an edge case where we do know a timestamp may naturally go backwards and provide some verbiage around how to handle this in the best practices section.

@broofa

• For Timestamp Granularity section I could put in some verbiage in "Fuzzing" sub-topic as a reason why somebody may fuzz the timestamp to handle leap seconds.
• Does the text in the next Counters section need to call this out too? https://uuid6.github.io/uuid6-ietf-draft/#section-6.2-14

[peterbourgon]

Fair, a note that time sources must be monotonic in the docs should be good.

[broofa]

More information: https://docs.ntpsec.org/latest/leapsmear.html provides a good description of the problem and possible solutions from the NTP perspective, and also provides guidance on when systems implement leap seconds via clock regression v. pausing v. "smearing". (E.g. if an app has legal requirements for using "correct" time, pausing and smearing should not be used.)

@kyzer-davis Mentioning this in the granularity and fuzzing sections makes sense. Additionally, it's probably appropriate to mention this in the section on dedicated counter length. For systems that don't implement leap smearing users will need to anticipate time intervals of up to ~1 second (real time) where the timestamp doesn't change, regardless of the normal timestamp resolution, and size the counter accordingly.

[sergeyprokhorenko]

the number of ids that occur during that interval may be 1000x more than expected, leading to a counter overflow

This must be avoided at all costs. UUIDs are not intended to be a source of precise UTC time (see section "Opacity"). Therefore, the timestamp of UUIDs may well differ from UTC by several seconds. The UUID generator MUST roll back all known leap seconds since the Unix Epoch. The leap seconds become known ahead of time, so this can be provided.

[sergeyprokhorenko]

With a strong desire, it is possible to calculate UTC time from such a timestamp, knowing when leap seconds were added.