Time-based UUID has less chance of conflict than random generated?

Question

Java UUID: time-based UUID has less chance of conflict than random generated?

Time-based: UUID generated at a timestamp will not conflict with any UUID generated before or after the timestamp.

But a random-generated UUID may conflict with an UUID generated sometime in the past or in the future.

Is this true? If true, why time-based UUID generation is not provided by Java?

Answer 1

Is this true?

It is true in theory. In practice:

1. MAC addresses are not necessarily unique¹.
2. Generating timestamps and the "uniquifying" clock sequence (see Wikipedia) is a hard problem ... unless UUID generation is implemented as machine-wide service.

Note that if timestamp + clock sequence are not generated correctly, the probability that the uniqueness is violated is likely to be higher that for type 4 UUIDs. (And that is pretty small ... )

If true, why time-based UUID generation is not provided by Java?

That is a question that can only be answered by the developers.

However, I think that the root problem is implementing the uniquifying clock sequence when you have multiple JVMs running on a machine. (Or when there are non-Java applications generating type 1 UUIDs.)

See the comments on https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5059271

---

Note that there are also potential security concerns with revealing MAC addresses via type 1 UUIDs, but that (IMO) is not a reason not to implement them ... for use-cases where MAC addresses don't need to be secret.

---

^{1 - Operating systems typically allow the default (manufacturer supplied) MAC address of a network interface to be overridden. And when you consider virtual machines, software defined networking and so on, the MAC addresses may be chosen randomly.}