ULIDs contains ILOU will be parsed as weird timestamps #69
Description
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 10889In 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