I have a use case where I want to retrofit uuidv7 IDs to a huge dataset.
All data is timestamped already, so in theory i could preserve the time order properties of the newly generated UUIDs even when not retrofitting all in the original order.
Would you be open to a PR that simply expands the generation interface by a std::chrono::time_point<std::chrono::system_clock> parameter?
- either overloading or adding a defaulted parameter to operator()
- forwarding it to get_new_state
If so, would it be fine to only support that in the v7 variant, not the other time based generators?
I'm no expert in UUIDs but the change to v7 seems minimal/risk free where I'm not really sure about v1/v6.
There seems to be precedence in other languages like rust and java.
Still I'm not sure if it is a good idea.
I have a use case where I want to retrofit uuidv7 IDs to a huge dataset.
All data is timestamped already, so in theory i could preserve the time order properties of the newly generated UUIDs even when not retrofitting all in the original order.
Would you be open to a PR that simply expands the generation interface by a
std::chrono::time_point<std::chrono::system_clock>parameter?If so, would it be fine to only support that in the v7 variant, not the other time based generators?
I'm no expert in UUIDs but the change to v7 seems minimal/risk free where I'm not really sure about v1/v6.
There seems to be precedence in other languages like rust and java.
Still I'm not sure if it is a good idea.