Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The microsecond provider uses more precise clock resolution to
create randomness values that should monotonically increase on
timestamp (millisecond) collision.
When creating a new ULID, we extract the number of microseconds from
our timestamp and use them as the first two bytes of the randomness value.
Caveats:
When using
ulid.from_timestamp
, we fallback to the default implementationof 10 bytes of pure randomness. The reason for this, is that the timestamp
that is being passed in by the caller is in milliseconds. Since we don't have
a more accurate timestamp to "steal" bytes from, there's not much we can do. We
cannot make a new epoch timestamp as the microsecond remainder is only accurate
when working within the same millisecond.
Status: Ready
If merged, this adds a microsecond implementation as discussed in #306 .
TODO:
new
provider methodUsage: