[Redbean] Add UuidV7 method

[mterron]

To Complete #1140 add UUID version 7 to Redbean

[mrdomino]

On looking at the spec, it says that the first 48 bits of a UUIDv7 should be the timestamp in milliseconds since the UNIX epoch. The rest is allowed to be random data, but is also allowed to be a sub-millisecond timestamp or monotonic counter (to ensure sortability at sub-millisecond resolution.)

I'm a bit confused about all the conversions vs bit arithmetic at the moment, but it doesn't look like that's what the current implementation is doing - is it?

I would suggest instead taking, as your 64-bit value, the following:

uint64_t now_ms = now.tv_sec * 1000 + now.tv_nsec / 1000000;

Put (the lower 48 bits of) that in the first 48 bits. Then you have a choice; there are about (just shy of) 20 bits of further entropy in the tv_nsec field, and at least on my system the first (just shy of) 10 bits are supposed to be accurate for time ordering. So if you wanted, you could have the next 10–20 bits of the UUID come from the lower-order bits of that field.

But you don't have to; you could just fill the rest of the UUID after the first 48 bits with random data.

(I have questions about rounding with regard to the nanosecond field in my proposed implementation but I don't think those are as important right now.)

[mterron]

On looking at the spec, it says that the first 48 bits of a UUIDv7 should be the timestamp in milliseconds since the UNIX epoch. The rest is allowed to be random data, but is also allowed to be a sub-millisecond timestamp or monotonic counter (to ensure sortability at sub-millisecond resolution.)

I'm a bit confused about all the conversions vs bit arithmetic at the moment, but it doesn't look like that's what the current implementation is doing - is it?

I would suggest instead taking, as your 64-bit value, the following:

uint64_t now_ms = now.tv_sec * 1000 + now.tv_nsec / 1000000;

Put (the lower 48 bits of) that in the first 48 bits. Then you have a choice; there are about (just shy of) 20 bits of further entropy in the tv_nsec field, and at least on my system the first (just shy of) 10 bits are supposed to be accurate for time ordering. So if you wanted, you could have the next 10–20 bits of the UUID come from the lower-order bits of that field.

But you don't have to; you could just fill the rest of the UUID after the first 48 bits with random data.

(I have questions about rounding with regard to the nanosecond field in my proposed implementation but I don't think those are as important right now.)

This is exactly what the implementation does actually. I have talked to Justine and have a less "magical" (or more explicit) implementation almost ready to push.

Thanks for the feedback! I won't try to be clever on my next commit.

[mrdomino]

Oh awesome, very good then. I dunno, cleverness is fine if it’s well documented, or if it’s clear enough that it doesn’t need to be documented.

[jart]

A few comments and requested changes, but overall LGTM.

[mrdomino]

LGTM

Remember to run clang-format.

[mterron]

LGTM

Remember to run clang-format.

I can do that, it makes it really ugly and hard to follow IMO though

[mrdomino]

If it's giving you trouble, then my opinion would be maybe don't worry about it for now and it can get cleaned up later.

[mterron]

If it's giving you trouble, then my opinion would be maybe don't worry about it for now and it can get cleaned up later.

Let's keep it this way and merge it then

[jart]

LGTM. Thank you!