Temporal: tests for IETF annotations standard #3683
Merged
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
As of tc39/proposal-temporal#2397 which reached consensus in the August 2022 TC39 meeting, a date-time + Z with no bracket annotation is no longer accepted as a relativeTo parameter; either the Z should be removed or a bracket annotation should be added. This requires adjusting a few existing tests, but doesn't require any new ones.
See tc39/proposal-temporal#2397 Adds tests for ISO strings with named and numeric offset time zone annotations, with and without the critical flag, with various combinations of Z and offset in front of the annotation.
See tc39/proposal-temporal#2397 Adds tests for ISO strings with calendar annotations, with and without the critical flag, and also a check that the second calendar annotation is disregarded, as per the IETF draft.
See tc39/proposal-temporal#2397 Adds tests for ISO strings with unrecognized annotations, (i.e., neither time zone nor calendar), in various combinations with recognized annotations.
See tc39/proposal-temporal#2397 Adds tests for ISO strings with unrecognized annotations with the critical flag. These strings should all be rejected.
See tc39/proposal-temporal#2397 Adds tests for ISO strings with more than one time zone annotation. These are not syntactically correct according to the grammar and should be rejected.
Since we are going to be adding a new test for calendarName: "critical", take the existing tests for various values of the calendarName option, and regularize them. Previously, depending on which type's toString() method was under test, the tests had various degrees of thoroughness, and some were only present in staging.
See tc39/proposal-temporal#2397 This normative change adds a new accepted value for the calendarName option in various toString() methods.
Based on the improvements just made to the calendarName option, improve the tests for the timeZoneName option of ZonedDateTime.prototype.toString as well.
See tc39/proposal-temporal#2397 This normative change adds a new accepted value for the timeZoneName option in ZonedDateTime.prototype.toString().
The programmer always gets the last word over how the string is interpreted, since otherwise it's not possible to make any guarantees about the offset option. (This is the "out-of-band" mechanism mentioned in the IETF draft.) Add a test for this.
Ms2ger
approved these changes
Oct 11, 2022
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 is another giant pull request, I recommend reviewing it commit by commit again.
Most of the tests in each commit are the same, so I'd recommend reviewing a representative sample in each commit; maybe pay special attention to Calendar.dateUntil, ZonedDateTime.from, ZonedDateTime.equals, and the compare() functions, since those are the ones where I sometimes had to do something out of the ordinary compared to the rest of the tests.
These tests are for the normative changes in tc39/proposal-temporal#2397 which reached consensus at the September 2022 TC39 meeting.