fix: set uuid._last_timestamp_v7 to reset uuid7 state

[decardev]

I came across this issue when using both freeegun and time_machine.

3.14::uuid7 keeps track of _last_timestamp_v7 to derive next value. To move forward and back in time this value must be re-set to None.

[pauloxnet]

Added a small code suggestion

[decardev]

Only to make mypy happy. What is prefered here?
@pytest.mark.skipif(...) or internal check?

[decardev]

I had to move the logic to the Traveller to resolve nesting or fixture usage.

[adamchainz]

You didn't provide a bug report. Please say what happens currently. An exception, faulty uuid generation, ...???

I'm not super in favour of adding a special patch in here for uuid7, since it's somewhat niche, and we could surely add similar patches for dozens of third-party libraries with a similar pattern of storing a timestamp. I'm leaning more towards making this a user responsibliity, but maybe something time-machine can assist with by providing something like a signals system for each time the time changes.

On that note, patching _start won't be sufficient: shift and move_to would also need changing.

[decardev]

You didn't provide a bug report. Please say what happens currently. An exception, faulty uuid generation, ...???

I'm not super in favour of adding a special patch in here for uuid7, since it's somewhat niche, and we could surely add similar patches for dozens of third-party libraries with a similar pattern of storing a timestamp. I'm leaning more towards making this a user responsibliity, but maybe something time-machine can assist with by providing something like a signals system for each time the time changes.

On that note, patching _start won't be sufficient: shift and move_to would also need changing.

Thank you for the feedback, #601.
Regarding the other points.

• This is targeting the standard uuid7 introduced on py314, not the third-party one. I completely agree that time_machine should not deal with third-party libraries, but given the introduction of UUID7 I think time_machine should cover it.
• It seems move_to calls _start() so it works and shift is a positive increase so no need to reset current timestamp.