Exactly. I wrote about that a few days ago.

Primary keys using UUID v7 are (potentially) an HR violation.

https://mikenotthepope.com/primary-keys-using-uuid-v7-are-po...

Which part is in violation of the age discrimination laws here, the fact that k-sortable uuids divulge the information, or the fact someone is using them to discriminate against a candidate?

If it’s the latter (which, reading wikipedias summary suggests it is), then the entire premise that k-sortable uuids are a “HR violation” is bunk.

The problem with arguing about timestamps leaking this kind of information is that _anything_ can leak this kind of vaguely dated information.

- Seen on a website that ceased to exist after 2010? Gotchya!

- Indexed by Waybackmachine? Gotchya!

- Used <different uuid scheme> for records created before 2022? Gotchya!

The only way to prevent divulging temporal clues about an entity is to never reveal its existence in any kind of correlatable way (which, as far as I’m prepared to think right now, seems to defeat the point of revealing it to a UI at all).

What's the scenario here?

I submit my application in 2025 and get rejected.

20 years later I submit another application to the same company, using my existing 20 years old user profile, and now get rejected because somebody figures out I'm old by looking at my user id?

Are there really any performances benefits of UUIDv7 over UUIDv4 that should ever come up in the context of an HR system? Just how many job applicants are you tracking?

I don't understand why you considered UUIDv7 in the first place.