Fundamental problem about javascript HOT 4 CLOSED

The spec states that time must be a 48 bit integer only. The extra bits the string encoding format allows for is simply extra space that will never be used.

So whenever you take the 10 time characters, and convert them into bits, you will always get an integer that fits inside 48 bits (it'll be zero padded for the few thousand years anyways!).

Said another way, even if the entire 48 bits for time is used, the largest base32 string you could get is 7ZZZZZZZZZ. Only if you encode a number that is greater than that, you will have the data-loss you described above. However, the spec makes it clear that this situation will only occur in approximately 9000 years. It does not intentionally specify what to do when that time comes 😄

from javascript.

That's right when you encode time from the right to the left, so when decoding, the 2 bits data lost on the left will have no effect because only 48 bits is used anyway. It's just limiting the max time you can encode like already stated on spec. But just by reading the spec some could potentially encode 50 bits; the string representation of time requires 10x 5bits; from the left to the right meaning the 2 bits on the right would be lost. Most base32 encoding algos encode from the left to the right. But, for ulid, time encoding using this will lead to data truncation and unable to decode back to the original string representation. For the 80 bits random part there is no problem because there is exactly 16 x 5bits so you can encode/decode from the left or right without problems.

from javascript.

from javascript.

Updated the docs slightly, closing this issue. You're more than welcome to submit a PR for more clarification!

from javascript.