You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Also would be interested in how the conversion between timeflake to UUID and back may work (e.g. what extra field needed for lossless conversion from UUID back to timeflake.
Also any NULL or MAX value available?
On a side note... I wonder why timeflake and ULID have fixed time precision and random ID length. Would it have made sense to allow for developers to adjust timestamp precision or random bit length (or even shrink it if they feel like it)?
If I'm speculating on what this may look like, this is what I would come up with.
<48b: Timestamp><Ext Timestamp>...<X Random bits><Ext Random>...
Extended Timestamp:
0bXXXX_XXX0 - Timestamp Extension Completed (X= Random Bits)
0bTTTT_TTT1 - Next Byte is extended sub milisecond precision timestamp
Extended Randomness:
0b0XXX_XXXX - No Change
0b1RRR_RRRR - Next Byte is extended randomness
The text was updated successfully, but these errors were encountered:
You can also start from a UUID and go to a timeflake and back, but it won't preserve the corresponding spec while as a timeflake, if that makes sense.
For example, UUIDv4 is almost completely random, which means if you turn that into a timeflake the timestamp component will be random and not ordered (you may get dates far in the past or future). But it works.
Regarding a configurable precision, I think it'd be certainly useful and appreciate you put thought into this, but I'd prefer to keep timeflake fixed in scope.
But this feature could definitely make for a separate library / unique ID spec with its own characteristics. Worth exploring if you're up for it.
Something similar to how https://github.com/ulid/spec#specification would be appreciated.
Also would be interested in how the conversion between timeflake to UUID and back may work (e.g. what extra field needed for lossless conversion from UUID back to timeflake.
Also any NULL or MAX value available?
On a side note... I wonder why timeflake and ULID have fixed time precision and random ID length. Would it have made sense to allow for developers to adjust timestamp precision or random bit length (or even shrink it if they feel like it)?
If I'm speculating on what this may look like, this is what I would come up with.
The text was updated successfully, but these errors were encountered: