tz: add Offset::round and fix Africa/Monrovia parsing
#234
Conversation
This file contains 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
This is to help support `Offset` equality that rounds to the nearest minute. It's also pretty easy to add since we can just reuse `SignedDuration::round`. We also add `TryFrom<SignedDuration> for Offset` and `From<Offset> for SignedDuration`. Closes #233
This new routine is like `resolve`, but permits callers to control how and when two offsets are considered equal. This is then in turn used by our Temporal datetime parser to permit parsing of offsets that have been rounded to the nearest minute without rejecting them for being unequal. Fixes #231
BurntSushi
force-pushed
the
ag/fix-offset-comparison
branch
from
bb325b7 to
dceb890
Compare
BurntSushi
added a commit
that referenced
this pull request
Feb 1, 2025
I meant to include this in #234, but it slipped my notice. Basically, if two offsets compare equal as-is, then it should always return true. Before this, if our parsed offset was `-00:44:30` and the time zone offset was `-00:44:30`, we were returning them as not equal because we skipped to rounding the latter to the nearest minute. I fixed this in the parser implementation but forgot to fix it in the doc example. That's what this commit does.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This adds a new
Offset::roundAPI in order to support fixing #231.Namely, previously, we would fail to parse zoned datetimes
like
1969-12-31T23:15:30-00:45[Africa/Monrovia]becauseAfrica/Monrovia's offset at the time was-00:44:30, which doesn'tmatch
-00:45:00. This in turn caused an error because Jiff's defaultbehavior is to reject parsed datetimes whose offset doesn't match a
valid offset in the corresponding time zone.
However, in this case, we want to accept it. What it comes down to
is that RFC 3339 and RFC 9557 do not support fractional minutes in
the offset. (I wonder why they flubbed that one.) So in order to
be compatible with existing implementations, Jiff serializes zoned
datetimes with fractional minutes by rounding to the nearest minute.
Hence why you might see
-00:45. But this in turn means Jiff wouldn'tbe able to parse a zoned datetime that itself serialized. Which is sad.
So in learning from Temporal here, we permit offsets from tzdb that
have fractional minutes to be rounded to the nearest minute before
being compared with the parsed offset. In this case,
-00:44:30getsrounded to
-00:45and thus compares equal with the parsed offset.Note though that the offset of the parsed zoned datetime is still,
correctly,
-00:44:30. It only becomes-00:45when serializing viathe Temporal datetime printer. (One can print an offset with second
precision via the
%zor%:zstrftimeconversion specifiers.)Ref tc39/proposal-temporal#3079
Fixes #231, Closes #233