Closed RedSpid3r closed 8 months ago
uuidv7.com seems to be broken. The leading 018e3f04-0218 indicates the millisecond Unix timestamp in hex and it points to the year 2024. uuidv7.com shows a wrong date too for the example UUIDv7 provided in the draft RFC.
Thanks for confirming. Will close this out :)
uuidv7.com seems to be broken. The leading 018e3f04-0218 indicates the millisecond Unix timestamp in hex and it points to the year 2024. uuidv7.com shows a wrong date too for the example UUIDv7 provided in the draft RFC.
I have adjusted to use the latest draft, the 018 example now correctly shows 2024.
https://github.com/RzNmKX/uuid7-flask/commit/93edde9e98248423dbf2ce6ae05a220551836218
I generated UUID
018e3f04-0218-7f62-8f86-6a3cfe5a42fb
on2024-03-14 22:02:48
however, when using the validator on https://uuid7.com/ it reports:UUIDv7 is valid with time: Sun, 27 Mar 1983 05:36:00 GMT
Is this a problem with this lib or a problem with uuidv7.com ?
This is now changed on https://uuid7.com - adjusted to use the latest draft: https://github.com/RzNmKX/uuid7-flask/commit/93edde9e98248423dbf2ce6ae05a220551836218
your example 018e3f04-0218-7f62-8f86-6a3cfe5a42fb
now returns Thu, 14 Mar 2024 22:10:11 GMT
. Are you sure you didn't do it at 22:10:11?
your example
018e3f04-0218-7f62-8f86-6a3cfe5a42fb
now returnsThu, 14 Mar 2024 22:10:11 GMT
. Are you sure you didn't do it at 22:10:11?
I guess it's possible I re-used that ID when i was testing. I just check the last entered ID in my db 018e791c-e8f6-7725-b5b8-7e8aa279cf4c
and this is correctly showing as Tue, 26 Mar 2024 04:55:21 GMT
on UUIDv7.com so it looks like everything is working as intended now 😄
I generated UUID
018e3f04-0218-7f62-8f86-6a3cfe5a42fb
on2024-03-14 22:02:48
however, when using the validator on https://uuid7.com/ it reports:UUIDv7 is valid with time: Sun, 27 Mar 1983 05:36:00 GMT
Is this a problem with this lib or a problem with uuidv7.com ?