-
Notifications
You must be signed in to change notification settings - Fork 157
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
Editorial: Various fixes #2670
Editorial: Various fixes #2670
Conversation
This is passed in the case where the method would otherwise be looked up on a string calendar.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2670 +/- ##
==========================================
+ Coverage 96.07% 96.10% +0.02%
==========================================
Files 20 20
Lines 11706 11771 +65
Branches 2186 2188 +2
==========================================
+ Hits 11247 11312 +65
Misses 395 395
Partials 64 64
☔ View full report in Codecov by Sentry. 📢 Have feedback on the report? Share it here. |
@@ -664,7 +664,6 @@ <h1> | |||
1. If _operation_ is ~subtract~, then | |||
1. Set _duration_ to ! CreateNegatedTemporalDuration(_duration_). | |||
1. Let _balanceResult_ be ? BalanceTimeDuration(_duration_.[[Days]], _duration_.[[Hours]], _duration_.[[Minutes]], _duration_.[[Seconds]], _duration_.[[Milliseconds]], _duration_.[[Microseconds]], _duration_.[[Nanoseconds]], *"day"*). | |||
1. Set _options_ to ? GetOptionsObject(_options_). |
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.
This actually does cause trouble, because options is passed through to CalendarDateAdd
and user code; see failing tests. The proposal in the issue to remove the second rather than the first call would presumably be better.
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.
Oops, I thought I had run the tests.
I think @gibson042 really did intend to remove the first call in #2586, since that's what he did for all the other types. How about what I've pushed now?
If built in debug mode, the constructor of each object defines a _repr_ property for use in the browser playground, and a custom util.inspect function for use in Node. In order to display ISO date time of exact times, or time zone and calendar annotations, this would have to perform user-observable operations. This actually made it harder to debug user-observable calls in debug mode! This changes the debug printing to be, as far as I know, side-effect-free. If the calendar or time zone is built-in (i.e. a string is stored in the internal slot), the output should be the same. If the calendar or time zone is an object and therefore has been exposed to user code, we don't get its ID and we don't print the local time in the time zone. Examples of what changed: PlainDate with custom calendar: before: "Temporal.PlainDate <2023-09-07[u-ca=cascadian]>" after: "Temporal.PlainDate <2023-09-07[u-ca=<calendar object>]>" ZonedDateTime with custom time zone: before: "Temporal.ZonedDateTime <2023-09-07T17:46:10-07:00[Custom/Cascadia]>" after: "Temporal.ZonedDateTime <2023-09-08T00:46:10Z[<time zone object>]>" Note that toString() does *not* change. This only modifies code that is not part of the proposal!
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.
LGTM
Fixes for various minor issues encountered while rebasing and writing tests for #2519. More info in each commit message. Best reviewed commit by commit.