Temporal API removals #4119
Merged
Temporal API removals #4119
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
91 tasks
ptomato
force-pushed
the
temporal-removals
branch
2 times, most recently
from
aa5fc0a
to
0af3bcc
Compare
justingrant
approved these changes
Jun 28, 2024
ptomato
force-pushed
the
temporal-removals
branch
from
0af3bcc
to
7251c7a
Compare
…nsition This is being moved to a method on Temporal.ZonedDateTime.prototype. It will not take a Temporal.Instant argument. See: tc39/proposal-temporal#2826
Temporarily replace them with getISOFields().calendar/timeZone just to keep the tests running until we remove Calendar and TimeZone objects altogether. See: tc39/proposal-temporal#2826
Some of the tests can be removed altogether since they deal with what forms of input can be passed to ToTemporalTimeZoneSlotValue. Those are tested on every method that takes a TimeZone as input. Other tests are still relevant, but need to move to ZonedDateTime.p.equals where the various quirks of time zone equality can still be tested. (Some of these still will be removed in a following commit because they use time zone objects.) See: tc39#2826
…zones These are tests that just won't apply anymore without custom calendars and time zones.
…stances In many cases we created a TimeZone or Calendar instance from a built-in time zone or calendar. These tests can be trivially adapted to just use the string ID.
…lpers It's no longer possible to fake built-in time zones using custom objects. So testing DST shifts will have to use real built-in time zones. Replace TemporalHelpers.springForwardFallBackTimeZone with America/Vancouver (it was modelled on the DST transitions in 2000) and TemporalHelpers.crossDateLineTimeZone with Pacific/Apia (it was modelled on the 2011 switch to the other side of the international date line.) These tests have to move to the intl402/ folder since non-Intl-aware implementations are allowed (but not required) to support any built-in time zones other than UTC.
…esses Many tests tested some functionality while asserting that there were no calls of calendar or time zone methods. We can continue testing the functionality, but there are no more methods to call, so we can delete those parts of the tests.
Test the "wrong type of object" with Duration objects where appropriate, otherwise just use plain objects.
This is no longer necessary if there are no calendar objects.
These are no longer possible without custom objects. Also add an exception for calendar and timeZone properties in property bag observers so they are not treated as objects.
…on-UTC time zone Without custom calendars and time zones there are actually a bunch of things that we now can't test on implementations that don't have non-ISO calendars or non-UTC time zones. (Alternatively, we can say that these are functionalities that those implementations don't have to implement.)
Previously getISOFields() was used to get the exact value of the [[Calendar]] and [[TimeZone]] internal slots, as well as to get the reference ISO year for PlainMonthDay and reference ISO day for PlainYearMonth. Use calendarId and timeZoneId for the former and toString() for the latter.
… time zone As in the previous commit, without custom calendars and time zones, some functionality cannot be tested on implementations that don't have any other calendars and time zones than iso8601 and UTC. Some of the staging tests fall in this category. We take the opportunity to port these into proper tests, in the intl402/ folder.
This test should trip if an implementation forgets to perform the removals that reached consensus in June 2024. (Although such an implementation would technically comply with the specification, if you really need to do that, please open an issue on the Temporal proposal repo rather than just skiplisting this test.)
…onstructors Now that we don't have to deal with strings or objects as input to the calendar ID or time zone ID parameter of constructors, we accept only the data that actually goes into the internal slots.
ptomato
added a commit
to ptomato/test262
that referenced
this pull request
Aug 21, 2024
…objs Tweak some tests to provide coverage of new execution paths in the spec, such as calling GetOptionsObject inside ToTemporal___; add a few new tests for things that weren't covered before, such as rounding a PlainDateTime at the edge of the range; and tweak the tests verifying when the properties of the options bag are read, which I made a mistake in tc39#4119. See: tc39/proposal-temporal#2925
ptomato
added a commit
to ptomato/test262
that referenced
this pull request
Aug 22, 2024
…objs Tweak some tests to provide coverage of new execution paths in the spec, such as calling GetOptionsObject inside ToTemporal___; add a few new tests for things that weren't covered before, such as rounding a PlainDateTime at the edge of the range; and tweak the tests verifying when the properties of the options bag are read, which I made a mistake in tc39#4119. See: tc39/proposal-temporal#2925
ptomato
added a commit
that referenced
this pull request
Aug 22, 2024
…objs Tweak some tests to provide coverage of new execution paths in the spec, such as calling GetOptionsObject inside ToTemporal___; add a few new tests for things that weren't covered before, such as rounding a PlainDateTime at the edge of the range; and tweak the tests verifying when the properties of the options bag are read, which I made a mistake in #4119. See: tc39/proposal-temporal#2925
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.
These are the test changes for the remaining API removals which reached TC39 consensus in June 2024: Temporal.Calendar, Temporal.TimeZone, the getCalendar methods, Temporal.ZonedDateTime.prototype.getTimeZone, and the getISOFields methods.
I'm well aware that this PR is thousands of files. I've tried to organize it logically into commits, so I recommend reviewing it commit by commit.
The bulk of the PR is the wholesale removal of 2250 files in the commit "Temporal: Remove tests directly relating to custom calendar and time zones". I would recommend skipping that one; you can verify mechanically that it's just file deletions.
That still leaves 1000 files to review. 200 of those are in "Temporal: Fix tests that unnecessarily create TimeZone or Calendar instances" which is a trivial, nearly mechanical replacement. Of the remaining 800, over half are spread out over the smaller commits, so shouldn't be too hard to review.
The only really tedious review will be of the commit "Temporal: Test adjustments for removing calendar and time zone objects", with 350 files, which consists of all of the various rewrites that we have to do, no way around it, that weren't easily organizable into other categories. However, a lot of these are deletions as well, so hopefully that's not too bad.
I'm open to suggestions for other ways to split this up to make reviews easier.