Closed IDisposable closed 5 months ago
The latest draft says that 36 bits are being reserved for the unix timestamp in order to extend the max timestamp until year 4147: https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-02.html#name-uuidv7-timestamp-usage
Does that address the concerns?
That spec changed since the last time I read it, sorry. I'll make the same suggestions to the spec author via the email on the spec. Thanks for pointing that out.
It at least mitigates the problem given that you're at the mercy of the timestamp size now, I think they need to change the V7 spec a bit to include the explicit ability/requirement to set the "leading 4 zeros" to actually be the number of epoch rollovers for the spec (and thus your inherited dependency) to be resilient.
My ultimate point being... when the rollover occurs ON a system where the timestamp is 32 bits, the v7 spec, and thus you by implementation will, if left unchanged, lead to a rolled-over value so after 2038-01-19 00:14:08. Those new rows will sort up to the top. :(
We should push for a better option (or revision to) UUID V7
From an email I sent the authors of that draft:
If we actually are building this to have some useful K-sortability, seems crazy to be asking for trouble and adopting a representation that will roll-over in 2038... that's not far away.