Different .time granularity on different platforms?

[CHerSun]

First of all, thank you for the package!

I've used UUID7 from your package as an ID (token) for user session - I want to use time stored in the token as a creation timestamp directly. And I want to invalidate the token after some time (a day). So what I did was to fetch .time from the UUID and compare it to current time.timestamp. Problem is - on different platforms UUID.time returns different order of values. As a workaround I have to divide by certain value to make it possible to compare.

Final function currently looks like this:

def check_token_expired(uuid: UUID, session_timeout_seconds: int) -> bool:
    """Check if session has expired by uuid v7 timestamp. Returns True if session IS expired."""
    assert isinstance(uuid, UUID)
    now_unix = datetime.now().timestamp()
    uuid_time = uuid.time
    if os.name == 'posix':
        uuid_time = uuid_time / 1000
    if os.name == 'nt':
        uuid_time = uuid_time / 1000000000
    return (now_unix - uuid_time) > session_timeout_seconds

Those os.name == ... comparissons look wrong to me. And it looks like the difference comes from uuid.time, not from datetime.now().timestamp(). Could you help checking this please?

Platforms I've tested on are Windows 10 and WSL with Ubuntu.

[oittaa]

Which Python version, and which uuid6 package version?

[oittaa]

The whole .time property is somewhat hidden even in the official UUID library. https://docs.python.org/3.11/library/uuid.html

For example the UUID7 .time implementation of this library has changed the returned values from nanosecond precision to millisecond precision when the official draft made the same change.

[CHerSun]

Sorry, I forgot to update this issue. It's no longer relevant. I'm not sure what, when and where (probably Python update) was changed, but one day there was no longer a difference in readings, so I could remove that workaround.