Simplify NumericDate conversions #693
Merged
timothee-haudebourg merged 1 commit intomainfrom Feb 2, 2026
Merged
Conversation
timothee-haudebourg
force-pushed
the
simpler-jwt-numeric-date
branch
from
c2ada14 to
36a758d
Compare
Juliano1612
approved these changes
Feb 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
The
NumericDatetype is overly concerned aboutf64precision, trying to prevent microseconds rounding errors for dates starting from year ~2200. Because of this it only provideTryFromconversions most of the time, instead of simplerFromconversions. But it's not being consistent either, withAddandSubimplementations usingunwrapeven though it might trigger rounding errors.This PR simplifies all of this by not caring about rounding errors by default anymore, and providing simple
Fromimplementations. If we do care about microseconds rounding errors at some point in the future, we can deal with it by adding safe methods and improving the internal representation ofNumericDate(usingf128for instance, or a lexical representation, etc.).