Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ULIDs contains ILOU will be parsed as weird timestamps #69

Open
kachick opened this issue May 1, 2021 · 4 comments · May be fixed by #119
Open

ULIDs contains ILOU will be parsed as weird timestamps #69

kachick opened this issue May 1, 2021 · 4 comments · May be fixed by #119

Comments

@kachick
Copy link
Contributor

kachick commented May 1, 2021

Hi! I'm writing a new Ruby library for handling ULID in these days.
Now I’m testing other implementations examples in kachick/ruby-ulid#53.

And I have found weird examples in original repository as ulid/javascript#85.

And then checked the parser of this library, because I'm using this in a Go project, it is so useful! 😄

Using this command line tool as below, the version is https://github.com/oklog/ulid/tree/e7ac4de44d238ff4707cc84b9c98ae471f31e2d1

$ ulid -h
Usage: ulid [-hlqz] [-f <format>] [parameters ...]
 -f, --format=<format>  when parsing, show times in this format: default, rfc3339, unix, ms
 -h, --help             print this help text
 -l, --local            when parsing, show local time instead of UTC
 -q, --quick            when generating, use non-crypto-grade entropy
 -z, --zero             when generating, fix entropy to all-zeroes

$ ulid 01111111111111111111111111
Mon Dec 19 08:09:04.801 UTC 2005

$ ulid 0LLLLLLLLLLLLLLLLLLLLLLLLL # `L` is same as `1` in https://www.crockford.com/base32.html, but returned different value
Tue Aug 02 05:31:50.655 UTC 10889

$ ulid 0UUUUUUUUUUUUUUUUUUUUUUUUU # `U` is invalid in https://www.crockford.com/base32.html, but does not raise error
Tue Aug 02 05:31:50.655 UTC 10889

$ ulid 00000000000000000000000000
Thu Jan 01 00:00:00 UTC 1970

$ ulid 0OOOOOOOOOOOOOOOOOOOOOOOOO # `O` is same as `0` in https://www.crockford.com/base32.html, but returned different value
Tue Aug 02 05:31:50.655 UTC 10889

In my understanding, Crockford's base32 does not contain L I O for the encoded product. So I think ULID can handle them as invalid values 🤔 ref: ulid/spec#38, kachick/ruby-ulid#57

@peterbourgon
Copy link
Member

peterbourgon commented May 3, 2021

Interesting. I think the relevant rules are

When decoding, upper and lower case letters are accepted, and i and l will be treated as 1 and o will be treated as 0. When encoding, only upper case letters are used.

Hyphens (-) can be inserted into symbol strings. This can partition a string into manageable pieces, improving readability by helping to prevent confusion. Hyphens are ignored during decoding.

I think we are not doing the bold parts.

@peterbourgon
Copy link
Member

@tsenart Think we can add those things?

@kachick
Copy link
Contributor Author

kachick commented May 3, 2021

Thanks for your comment!

I think we are not doing the bold parts.

Agreed, and I think ignoring them is the desirable spec for actual use-case, rather than strict following original Crockford's base32. 😅

So I have suggested it in ulid/spec#57 🙏

@peterbourgon
Copy link
Member

Ah, yes, and to just make it explicit, you wrote

Especially when [implementations] accept [the] iIlLoO mapping, as [is suggested in the] original Crockford's base32 decoding spec, Lexicographically sortable is lost

which is a great point 👍 Will wait for the outcome of that other PR...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants