Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 9562: Universally Unique IDentifiers (May 2024)

rfc-editor.org

Post reply on HN
Print view View original

21–30 of 48 posts

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#21

Post by wrs »

LegionMammal978 wrote: post #14

> UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded. That seems like a rather vague way of addressing leap seconds for UUIDv7. For positive leap seconds, an 'exclusion' of that second would suggest that the millisecond counter is halted until the leap second is over,…

I interpreted it to mean the timer is monotonic and ignores leap seconds completely. It does make it easy to implement wrong if your most convenient time API does implement leap seconds. (I don’t see why this would have anything to do with the millisecond timer? Leap seconds happen on the second.)

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#22

Post by debatem1 »

free_bip wrote: post #12
ComplexSystems wrote: post #4

Surprising we're using 128 bits - some back of the napkin math tells me that may not be enough to avoid collisions...

The time field ensures that collisions cannot occur until at minimum the time field rolls over.

Having been badly bitten by the timestamp equivalent of eating gum you scraped off the bottom of a desk just let me add that there is an implicit "if your time source is good/non-adversarial" assumption here.

Friends don't let friends use malicious clocks!

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#23

Post by londons_explore »

> UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds

This just seems to be a way of creating a huge class of subtle bugs. Now, when two things happen to be created in the same millisecond, they may or may not be monotonically increasing.

Plenty of systems will end up accidentally depending on the ordering of the UUID's being the same order the UUID's were generated in. And that will hold true till the system hits production and suddenly there is enough load for that not to be true for a handful of records and the whole system fails.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#24

Post by LegionMammal978 »

anamexis wrote: post #18
LegionMammal978 wrote: post #14

> UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded. That seems like a rather vague way of addressing leap seconds for UUIDv7. For positive leap seconds, an 'exclusion' of that second would suggest that the millisecond counter is halted until the leap second is over,…

There will not be any leap seconds after 2035, and very likely there will never be any negative leap seconds.

That's plenty of time for the CGPM to change its mind, or to implement some other mechanism to bound the UT1 − UTC difference. It will eventually be an issue in any case, since it's not like they decided to let the difference grow without bound.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#25

Post by ComplexSystems »

AaronFriel wrote: post #10
ComplexSystems wrote: post #4

Surprising we're using 128 bits - some back of the napkin math tells me that may not be enough to avoid collisions...

Care to share your math? My understanding of the birthday paradox is that it is astoundingly unlikely.

It's just about on the cusp. We would need to generate 1.1774sqrt(2^128) UUID's before getting a collision with 51% probability. That's about 2.17 10^19 total UUIDs.

The real question is how many UUIDs are generated per second around the world. This RFC suggests using them for automated processes, transactions, etc and generally seems to view them as an inexhaustible resource. If humanity collectively generates 1 trillion per second we can expect to see a 51% chance of collision in 8 months; if it's 100 billion it'd be 10 years, and if it's only 10 billion it'd be 100 years. I would expect even just one single computer with a modest GPU could get in the ballpark of these numbers if it wanted to just spawn UUIDs all day, let alone a huge server farm using them as part of some automated process.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#26

Post by LegionMammal978 »

wrs wrote: post #21
LegionMammal978 wrote: post #14

> UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded. That seems like a rather vague way of addressing leap seconds for UUIDv7. For positive leap seconds, an 'exclusion' of that second would suggest that the millisecond counter is halted until the leap second is over,…

I interpreted it to mean the timer is monotonic and ignores leap seconds completely. It does make it easy to implement wrong if your most convenient time API does implement leap seconds. (I don’t see why this would have anything to do with the millisecond timer? Leap seconds happen on the second.)

Unix timestamps are not monotonic when a positive leap second is applied: the next day must always start at a multiple of 86400 seconds, even if the UTC day is 86401 seconds long. Unless some part of the day is smeared, the timestamp must be set back at some point. So either the UUIDv7 timer is not monotonic, or it does not align with Unix timestamps.

As for the millisecond timer, recall that a positive leap second lasts for 1000 milliseconds. So to 'exclude' the leap second, by one interpretation, would be to exclude each of those milliseconds individually as they arise; in other words, to halt the timer during the leap second.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#27

Post by anamexis »

LegionMammal978 wrote: post #26
wrs wrote: post #21

Earlier quoted context omitted.

I interpreted it to mean the timer is monotonic and ignores leap seconds completely. It does make it easy to implement wrong if your most convenient time API does implement leap seconds. (I don’t see why this would have anything to do with the millisecond timer? Leap seconds happen on the second.)

Unix timestamps are not monotonic when a positive leap second is applied: the next day must always start at a multiple of 86400 seconds, even if the UTC day is 86401 seconds long. Unless some part of the day is smeared, the timestamp must be set back at some point. So either the UUIDv7 timer is not monotonic, or it does not align with Unix timestamps. As for the millisecond timer, recall that a positive leap second l…

The way I read it, they don't claim to align with Unix timestamps. They claim being aligned with the same source time.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#29

Post by LegionMammal978 »

anamexis wrote: post #27
LegionMammal978 wrote: post #26

Earlier quoted context omitted.

Unix timestamps are not monotonic when a positive leap second is applied: the next day must always start at a multiple of 86400 seconds, even if the UTC day is 86401 seconds long. Unless some part of the day is smeared, the timestamp must be set back at some point. So either the UUIDv7 timer is not monotonic, or it does not align with Unix timestamps. As for the millisecond timer, recall that a positive leap second l…

The way I read it, they don't claim to align with Unix timestamps. They claim being aligned with the same source time.

As I read it, the value is specifically aligned with "the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded". (And they really must not have been considering the rubber seconds in UTC up to 1972!)

Consider a day ending in a positive leap second. Suppose that at 23:59:59.500...Z, the millisecond counter is at T − 500. By the start of the leap second (23:59:59.999...Z), the millisecond counter is at T. Then, at the end of the leap second (00:00:00.000...Z), the counter must be at T, since the leap second must excluded from the counter by definition. By 00:00:00.500...Z, it's at T + 500, and so on.

The question is, what is the value of the counter between 23:59:59.999...Z (when it is at T) and 00:00:00.000...Z (when it is at T), during the course of the leap second? The definition doesn't make this clear.

Re: RFC 9562: Universally Unique IDentifiers (May 2024)

#30

Post by t0mas88 »

ComplexSystems wrote: post #25
AaronFriel wrote: post #10

Earlier quoted context omitted.

Care to share your math? My understanding of the birthday paradox is that it is astoundingly unlikely.

It's just about on the cusp. We would need to generate 1.1774 sqrt(2^128) UUID's before getting a collision with 51% probability. That's about 2.17 10^19 total UUIDs. The real question is how many UUIDs are generated per second around the world. This RFC suggests using them for automated processes, transactions, etc and generally seems to view them as an inexhaustible resource. If humanity collectively generates 1 tr…

But not all UUIDS are going into the same "pool". There is no problem if your GPU generates a collision with one of my database identifies, since I only care about my identifiers being unique in my system.

For comparison, before UUIDs most databases were using auto increment integers. That means nearly everyone had id 1, 2 etc in use. Still not a problem.

Post reply on HN