Test that non-string Temporal.TimeZone IDs will throw #3881
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
justingrant
force-pushed
the
custom-timezone-id-must-be-string
branch
2 times, most recently
from
68c0f0e
to
b672404
Compare
This commit fills a test hole found by Codecov: we weren't checking for the case of a custom time zone whose `id` property returns a non-string value. Note that the `id` property is only read in a few places, all on the ZonedDateTime prototype: `until`, `since`, `equals`, `toString`, `toLocaleString`, `toJSON`, and `timeZoneId`.
Ms2ger
force-pushed
the
custom-timezone-id-must-be-string
branch
from
b672404
to
6fc6319
Compare
FYI @ptomato: there may be a test gap for non-string custom calendar IDs. Where is the best place to record that this gap exists? Issue here in Test262 repo? In proposal-temporal repo? Somewhere else? I probably won't be able to PR that, but at least wanted to record that the gap (probably) exists. |
|
I created one here |
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 PR fills a test hole found by Codecov: we weren't checking for the case of a custom time zone whose
idproperty returns a non-string value.The
idproperty is only read in a few places, all on the ZonedDateTime prototype:until,since,equals,toString,toLocaleString,toJSON, andtimeZoneId.Note that the same test gap seems to exist for custom calendars too, so a future PR will be needed to fill that gap.