-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: nested property bags and ISO strings in Calendar/TimeZone.from #2485
Conversation
Could we make this a draft PR until we have consensus on desired behavior? |
c7ee0f8
to
c9b5ffc
Compare
c9b5ffc
to
4272b58
Compare
Codecov Report
@@ Coverage Diff @@
## main #2485 +/- ##
==========================================
+ Coverage 95.91% 95.97% +0.05%
==========================================
Files 20 20
Lines 11115 11123 +8
Branches 2114 2126 +12
==========================================
+ Hits 10661 10675 +14
+ Misses 392 387 -5
+ Partials 62 61 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Previously, "nested" time zone property bags were unwrapped up to one level. That is, this object: { timeZone: { // ...Temporal.TimeZone methods } } would not be considered to implement the TimeZone protocol, but would have its timeZone property used instead, if it were passed to an API that required a TimeZone protocol object. These nested property bags are no longer supported. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Previously, "nested" calendar property bags were unwrapped up to one level. That is, this object: { calendar: { // ...Temporal.Calendar methods } } would not be considered to implement the Calendar protocol, but would have its calendar property used instead, if it were passed to an API that required a Calendar protocol object. These nested property bags are no longer supported. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Checking whether an object implements the TimeZone protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the TimeZone brand. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Checking whether an object implements the Calendar protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the Calendar brand. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
4272b58
to
e243b13
Compare
Thanks for the reviews. For the record, this PR got consensus in the January/February 2023 TC39 meeting. The only remaining obstacle for merging it is test262 tests, which I've just opened a PR for: tc39/test262#3813 |
Previously, "nested" time zone property bags were unwrapped up to one level. That is, this object: { timeZone: { // ...Temporal.TimeZone methods } } would not be considered to implement the TimeZone protocol, but would have its timeZone property used instead, if it were passed to an API that required a TimeZone protocol object. These nested property bags are no longer supported. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Previously, "nested" calendar property bags were unwrapped up to one level. That is, this object: { calendar: { // ...Temporal.Calendar methods } } would not be considered to implement the Calendar protocol, but would have its calendar property used instead, if it were passed to an API that required a Calendar protocol object. These nested property bags are no longer supported. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Checking whether an object implements the TimeZone protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the TimeZone brand. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Checking whether an object implements the Calendar protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the Calendar brand. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Previously, "nested" time zone property bags were unwrapped up to one level. That is, this object: { timeZone: { // ...Temporal.TimeZone methods } } would not be considered to implement the TimeZone protocol, but would have its timeZone property used instead, if it were passed to an API that required a TimeZone protocol object. These nested property bags are no longer supported. Discussion: #2104 (comment) See: #2104
Previously, "nested" calendar property bags were unwrapped up to one level. That is, this object: { calendar: { // ...Temporal.Calendar methods } } would not be considered to implement the Calendar protocol, but would have its calendar property used instead, if it were passed to an API that required a Calendar protocol object. These nested property bags are no longer supported. Discussion: #2104 (comment) See: #2104
Checking whether an object implements the TimeZone protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the TimeZone brand. Discussion: #2104 (comment) See: #2104
Checking whether an object implements the Calendar protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the Calendar brand. Discussion: #2104 (comment) See: #2104
Previously, "nested" time zone property bags were unwrapped up to one level. That is, this object: { timeZone: { // ...Temporal.TimeZone methods } } would not be considered to implement the TimeZone protocol, but would have its timeZone property used instead, if it were passed to an API that required a TimeZone protocol object. These nested property bags are no longer supported. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Previously, "nested" calendar property bags were unwrapped up to one level. That is, this object: { calendar: { // ...Temporal.Calendar methods } } would not be considered to implement the Calendar protocol, but would have its calendar property used instead, if it were passed to an API that required a Calendar protocol object. These nested property bags are no longer supported. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Checking whether an object implements the TimeZone protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the TimeZone brand. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
Checking whether an object implements the Calendar protocol is now done by means of HasProperty operations for each of the required methods unless the object already has the Calendar brand. Discussion: tc39/proposal-temporal#2104 (comment) Corresponding normative PR: tc39/proposal-temporal#2485
e243b13
to
11a811f
Compare
I believe this was a rebase error in #2485 which I didn't catch in review.
I believe this was a rebase error in #2485 which I didn't catch in review.
I believe this was a rebase error in #2485 which I didn't catch in review.
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182025 Differential Revision: https://phabricator.services.mozilla.com/D182026
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182026 Differential Revision: https://phabricator.services.mozilla.com/D182027
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182025 Differential Revision: https://phabricator.services.mozilla.com/D182026
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182026 Differential Revision: https://phabricator.services.mozilla.com/D182027
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182025 Differential Revision: https://phabricator.services.mozilla.com/D182026 UltraBlame original commit: a26950114649f104836074e06d726358ba94c048
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182026 Differential Revision: https://phabricator.services.mozilla.com/D182027 UltraBlame original commit: 12e79d0c699efde090bcded208f9585c35dfd856
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182025 Differential Revision: https://phabricator.services.mozilla.com/D182026 UltraBlame original commit: a26950114649f104836074e06d726358ba94c048
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182026 Differential Revision: https://phabricator.services.mozilla.com/D182027 UltraBlame original commit: 12e79d0c699efde090bcded208f9585c35dfd856
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182025 Differential Revision: https://phabricator.services.mozilla.com/D182026 UltraBlame original commit: a26950114649f104836074e06d726358ba94c048
…ue. r=spidermonkey-reviewers,sfink Implement the changes from <tc39/proposal-temporal#2485>. The function name hasn't yet been updated to reflect the new name. Depends on D182026 Differential Revision: https://phabricator.services.mozilla.com/D182027 UltraBlame original commit: 12e79d0c699efde090bcded208f9585c35dfd856
Closes: #2104
Note, this PR is staged on top of #2482. For review purposes, look only at the last four commits, or look at this comparison.