🐛 fix: zero not being a valid time #14
Conversation
lukas-runge
changed the title
|
Hi! It's currently a documented (positive integer) limitation of the generator. Zero |
|
P.S. This limitation is introduced to this library because I reused the design of generator implemented in other languages, where timestamp is unsigned or initializing int at zero is very convenient. |
|
Hi @LiosK, thank you for your fast reply and for pointing out that I broke that condition in my special case and wasn't even generating proper uuids. 73cc1ab should fix this without impacting performance or handling, thereby lifting the limitation. 🥳 Even tho you are absolutely right, that this special case will most likely not occur in production, being able to test with mocked time starting from timestamp 0 is very convenient. As all data is usually initialized at the beginning of a every test, this would otherwise require initializing system time to some arbitrary value, which sounds more like a workaround than a solution. 🙌 Best regards, |
|
Hi! I'm currently not planning to lift this limitation, unfortunately. I'm maintaining several implementations that share the same design in different languages, so at this stage I don't really like to specialize the typescript implementation only. |
Greetings @jetify-com Team, 👋 when running some of my unit tests using time mocking I discovered that a time of `0` currently spawns a `RangeError` in `uuidv7` even tho it's a perfectly valid time. This special case will most likely not occur in production, nevertheless being able to test with mocked time starting from timestamp zero is very convenient. As all data is usually initialized at the beginning of a every test, this would otherwise require initializing system time to some arbitrary value, which sounds more like a workaround than a solution. As this is a limitation of the `uuidv7` library I proposed a fix to @LiosK that would lift this limitation without impacting performance or handling: LiosK/uuidv7#14 (comment) Sadly he is not interested in lifting this limitation and won't merge the fix. This PR aims to fix this issue on your end by migrating from https://github.com/LiosK/uuidv7 to https://github.com/uuidjs/uuid which seems to be more widely adopted and better maintained anyway. I also tested performance and found it to be marginally better. For a a quick reproduction of the issue checkout: https://github.com/lukas-runge/typeid-zero-not-being-a-valid-time 🙌 Best regards, @lukas-runge
Greetings @jetify-com Team, 👋 when running some of my unit tests using time mocking I discovered that a time of `0` currently spawns a `RangeError` in `uuidv7` even tho it's a perfectly valid time. This special case will most likely not occur in production, nevertheless being able to test with mocked time starting from timestamp zero is very convenient. As all data is usually initialized at the beginning of a every test, this would otherwise require initializing system time to some arbitrary value, which sounds more like a workaround than a solution. As this is a limitation of the `uuidv7` library I proposed a fix to @LiosK that would lift this limitation without impacting performance or handling: LiosK/uuidv7#14 (comment) Sadly he is not interested in lifting this limitation and won't merge the fix. This PR aims to fix this issue on your end by migrating from https://github.com/LiosK/uuidv7 to https://github.com/uuidjs/uuid which seems to be more widely adopted and better maintained anyway. I also tested performance and found it to be marginally better. For a a quick reproduction of the issue checkout: https://github.com/lukas-runge/typeid-zero-not-being-a-valid-time 🙌 Best regards, @lukas-runge
Hi @LiosK,
when running some of my unit tests using time mocking I discovered that a time of
0currently spawns a RangeError even tho it's a perfectly valid time. This PR aims to fix that. 🙌Best regards,
@lukas-runge