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

31–40 of 48 posts

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

#31

Post by deathanatos »

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.

What is "source time", to you?

Like, I have a timestamp, in the format YYYY-MM-DD HH:MM:SS.ffff Z. What rules do I use to translate that into/from a set of bits? Whatever answer you give here, it seems like it must run afoul of the problems the parent poster is pointing out!

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

#32

Post by fanf2 »

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,…

That’s the normal way IETF RFCs describe unix seconds since the epoch, though there ought to be a normative reference to https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

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

#34

Post by AaronFriel »

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…

True, as universally unique identifiers, 128 (less a few) bits is not enough. You're talking about humanity generating 505 exabytes per year of just UUIDs. That won't happen any time soon.

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

#35

Post by anamexis »

deathanatos wrote: post #31
anamexis wrote: post #27

Earlier quoted context omitted.

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

What is "source time", to you? Like, I have a timestamp, in the format YYYY-MM-DD HH:MM:SS.ffff Z. What rules do I use to translate that into/from a set of bits? Whatever answer you give here, it seems like it must run afoul of the problems the parent poster is pointing out!

Count the number of seconds that have elapsed from the Unix epoch time until that moment, excluding leap seconds. This increases monotonically and is consistent with the Unix epoch source time.

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

#36

Post by LegionMammal978 »

anamexis wrote: post #35
deathanatos wrote: post #31

Earlier quoted context omitted.

What is "source time", to you? Like, I have a timestamp, in the format YYYY-MM-DD HH:MM:SS.ffff Z. What rules do I use to translate that into/from a set of bits? Whatever answer you give here, it seems like it must run afoul of the problems the parent poster is pointing out!

Count the number of seconds that have elapsed from the Unix epoch time until that moment, excluding leap seconds. This increases monotonically and is consistent with the Unix epoch source time.

At 2016-12-31T23:59:59.999Z, 1483228799.999 seconds had elapsed from the epoch, excluding leap seconds, according to "Unix epoch source time".

At 2017-01-01T00:00:00.000Z, 1483228800.000 seconds had elapsed from the epoch, excluding leap seconds, according to "Unix epoch source time".

Now, at 2016-12-31T23:59:60.500Z, how many seconds had elapsed from the epoch, exluding leap seconds? What about 2016-12-31T23:59:60.000Z, or 2016-12-31T23:59:60.750Z? The only monotonic solution is for all of these to have the exact same timesamp of 1483228800.000 seconds. But then that runs into a thousandfold increase in collision probability.

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

#37

Post by LegionMammal978 »

fanf2 wrote: post #32
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,…

That’s the normal way IETF RFCs describe unix seconds since the epoch, though there ought to be a normative reference to https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

The problem with "seconds since the Epoch" is that if you naively add milliseconds, it is no longer monotonic.

Since 2016-12-31T23:59:60Z is 1483228800 seconds since the Epoch, and 2017-01-01T00:00:00Z is also 1483228800 seconds since the Epoch, that means that 2016-12-21T23:59:60.xxxZ would have the same timestamp as 2017-01-01T00:00:00.xxxZ, for all xxx.

This corresponds to the counter jumping backward 1000 milliseconds at 2017-01-01T00:00:00.000Z.

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

#38

Post by anamexis »

LegionMammal978 wrote: post #36
anamexis wrote: post #35

Earlier quoted context omitted.

Count the number of seconds that have elapsed from the Unix epoch time until that moment, excluding leap seconds. This increases monotonically and is consistent with the Unix epoch source time.

At 2016-12-31T23:59:59.999Z, 1483228799.999 seconds had elapsed from the epoch, excluding leap seconds, according to "Unix epoch source time". At 2017-01-01T00:00:00.000Z, 1483228800.000 seconds had elapsed from the epoch, excluding leap seconds, according to "Unix epoch source time". Now, at 2016-12-31T23:59:60.500Z, how many seconds had elapsed from the epoch, exluding leap seconds? What about 2016-12-31T23:59:60.0…

You can use whatever solution you want - hold the timestamp, smear time, it's up to you. It's still monotonic, and uses the same epoch.

You've still got 74 random bits.

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

#39

Post by ComplexSystems »

AaronFriel wrote: post #34
ComplexSystems wrote: post #25

Earlier quoted context omitted.

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…

True, as universally unique identifiers, 128 (less a few) bits is not enough. You're talking about humanity generating 505 exabytes per year of just UUIDs. That won't happen any time soon.

Of course it will:

"The UUID generation algorithm described here supports very high allocation rates of 10 million per second per machine or more, if necessary, so that they could even be used as transaction IDs."

This is the use case they had in mind when building this algorithm, and it would only take about 10k machines worldwide to reach the above levels.

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

#40

Post by vhcr »

londons_explore wrote: post #23

> 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…

Monotonicity is addressed in section 6.2, but it's optional.
Post reply on HN