Normative: Calendar and TimeZone removals #2925
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
This was referenced Jul 27, 2024
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
4047d55
to
493ce51
Compare
91 tasks
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
493ce51
to
74ec1c7
Compare
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
74ec1c7
to
ffa4bd6
Compare
ptomato
force-pushed
the
calendar-time-zone-removals
branch
2 times, most recently
from
49b2b3e
to
ec7cdcb
Compare
ptomato
added a commit
that referenced
this pull request
Aug 20, 2024
The spec text uses ToTemporalPartialDurationRecord here, not PrepareTemporalFields. This is relevant because we are going to refactor PrepareTemporalFields as part of #2925.
ptomato
added a commit
that referenced
this pull request
Aug 20, 2024
ToTemporalTimeRecord can be simplified quite a lot and doesn't need to call the more complicated PrepareTemporalFields. This change is unobservable, but it's preparation for refactoring PrepareTemporalFields in #2925.
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
ec7cdcb
to
c86abf6
Compare
ptomato
added a commit
that referenced
this pull request
Aug 21, 2024
ToTemporalTimeRecord can be simplified quite a lot and doesn't need to call the more complicated PrepareTemporalFields. This change is unobservable, but it's preparation for refactoring PrepareTemporalFields in #2925.
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
c86abf6
to
2b549d0
Compare
ptomato
added a commit
that referenced
this pull request
Aug 21, 2024
The spec text uses ToTemporalPartialDurationRecord here, not PrepareTemporalFields. This is relevant because we are going to refactor PrepareTemporalFields as part of #2925.
ptomato
added a commit
that referenced
this pull request
Aug 21, 2024
ToTemporalTimeRecord can be simplified quite a lot and doesn't need to call the more complicated PrepareTemporalFields. This change is unobservable, but it's preparation for refactoring PrepareTemporalFields in #2925.
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
force-pushed
the
calendar-time-zone-removals
branch
from
2b549d0
to
2fa1b21
Compare
|
This is ready for review now. There is a small amount of additional and tweaked test coverage, in tc39/test262#4206. |
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
to tc39/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 #4119. See: tc39/proposal-temporal#2925
Ms2ger
approved these changes
Aug 23, 2024
justingrant
approved these changes
Aug 25, 2024
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
ef56146
to
aa339b8
Compare
Hopefully this will fix uploading code coverage reports, at least temporarily. (This uploader is deprecated and they want you to migrate to the GitHub Action.)
|
Amazing work on this, @ptomato ! 🙏 |
This was referenced Sep 9, 2024
bartlomieju
pushed a commit
to denoland/deno
that referenced
this pull request
Sep 10, 2024
…25505) Mainly I removed `Temporal.Calendar` and `Temporal.TimeZone` and replaced them to APIs that handle calendar and timezone as strings. tc39/proposal-temporal#2925 Related #24836
ptomato
added a commit
that referenced
this pull request
Oct 1, 2024
Similarly to the previous commit, we must avoid calling GetUTCEpochNanoseconds with dates that are too large because it is ill-defined in ECMA-262 what is supposed to happen. (See tc39/ecma262#1087). Previously to PR #2925, that could not happen because GetPossibleInstantsFor took a PlainDateTime object, but now it takes an ISO Date-Time Record. Note that this is editorial, because IsValidEpochNanoseconds would throw anyway in this case even if GetUTCEpochNanoseconds was fully defined for large inputs.
ptomato
added a commit
that referenced
this pull request
Oct 2, 2024
Similarly to the previous commit, we must avoid calling GetUTCEpochNanoseconds with dates that are too large because it is ill-defined in ECMA-262 what is supposed to happen. (See tc39/ecma262#1087). Previously to PR #2925, that could not happen because GetPossibleInstantsFor took a PlainDateTime object, but now it takes an ISO Date-Time Record. Note that this is editorial, because IsValidEpochNanoseconds would throw anyway in this case even if GetUTCEpochNanoseconds was fully defined for large inputs.
ptomato
added a commit
that referenced
this pull request
Oct 2, 2024
Similarly to the previous commit, we must avoid calling GetUTCEpochNanoseconds with dates that are too large because it is ill-defined in ECMA-262 what is supposed to happen. (See tc39/ecma262#1087). Previously to PR #2925, that could not happen because we used a PlainDateTime object in InterpretISODateTimeOffset, but now we use an ISO Date-Time Record. Note that this is editorial, because IsValidEpochNanoseconds would throw anyway in this case even if GetUTCEpochNanoseconds was fully defined for large inputs.
Ms2ger
pushed a commit
that referenced
this pull request
Oct 3, 2024
Similarly to the previous commit, we must avoid calling GetUTCEpochNanoseconds with dates that are too large because it is ill-defined in ECMA-262 what is supposed to happen. (See tc39/ecma262#1087). Previously to PR #2925, that could not happen because GetPossibleInstantsFor took a PlainDateTime object, but now it takes an ISO Date-Time Record. Note that this is editorial, because IsValidEpochNanoseconds would throw anyway in this case even if GetUTCEpochNanoseconds was fully defined for large inputs.
Ms2ger
pushed a commit
that referenced
this pull request
Oct 3, 2024
Similarly to the previous commit, we must avoid calling GetUTCEpochNanoseconds with dates that are too large because it is ill-defined in ECMA-262 what is supposed to happen. (See tc39/ecma262#1087). Previously to PR #2925, that could not happen because we used a PlainDateTime object in InterpretISODateTimeOffset, but now we use an ISO Date-Time Record. Note that this is editorial, because IsValidEpochNanoseconds would throw anyway in this case even if GetUTCEpochNanoseconds was fully defined for large inputs.
ptomato
added a commit
that referenced
this pull request
Oct 4, 2024
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
ptomato
added a commit
that referenced
this pull request
Oct 4, 2024
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
ptomato
added a commit
that referenced
this pull request
Oct 7, 2024
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
ptomato
added a commit
that referenced
this pull request
Oct 7, 2024
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
Ms2ger
pushed a commit
that referenced
this pull request
Oct 8, 2024
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
Ms2ger
pushed a commit
that referenced
this pull request
Oct 8, 2024
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962
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 the remaining followup from #2895 and #2914, implementing the conclusions from the June 2024 TC39 meeting.
It is stacked on top of the editorial PR #2922.Some editorial simplifications still to be done on this PR.