Skip to content
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

Remove plainDateTimeOrRelativeToWillBeUsed #2836

Closed
ptomato opened this issue May 10, 2024 · 1 comment
Closed

Remove plainDateTimeOrRelativeToWillBeUsed #2836

ptomato opened this issue May 10, 2024 · 1 comment
Assignees

Comments

@ptomato
Copy link
Collaborator

ptomato commented May 10, 2024

From #2758 reviews. This can likely be drastically simplified after #2826 lands and can maybe even be done as part of that issue.

This plainDateTimeOrRelativeToWillBeUsed is a little hard to reason about. Here's how you can make it clearer. Feel free to queue this up as an Editorial task for later if the goal here is keep the diff as small as possible.

You can determine whether nanosecond-rounding is possible at the beginning of the function and it makes things clearer. Pseudocode:

const needRelativeRounding =
  zonedRelativeTo || // if zoned date time
  // OR, if plain date and there's a unit >DAY
  ES.IsCalendarUnit(largestUnit) ||
  calendarUnitsPresent

if (!needRelativeRounding) {
  // do nanosecond-based rounding (BalanceTimeDuration)
  // return the result here, short circuiting
}

if (!zonedRelativeTo || !plainRelativeTo) {
  throw new RangeError('need a relativeTo')
}

const calendarRec = CalendarMethodRecord.CreateFromRelativeTo(plainRelativeTo, zonedRelativeTo, [
  'dateAdd',
  'dateUntil'
]);

if (zonedRelativeTo) {
  const precalculatedPlainDateTime = // ...
  // proceed with DifferenceZonedDateTimeWithRounding...
} else if (plainRelativeTo) {
  // proceed with DifferencePlainDateTimeWithRounding...
}

Originally posted by @arshaw in #2758 (comment)

@ptomato
Copy link
Collaborator Author

ptomato commented Jul 29, 2024

This is done as part of #2925.

ptomato added a commit that referenced this issue Aug 22, 2024
This is a very large change, as it not only removes Temporal.Calendar and
Temporal.TimeZone, but also tries to eliminate any extra complexity due to
no longer having to deal with user code calls for calendar and time zone
calculations.

Some of the things that are removed or simplified include:

- No more Calendar Method Records and Time Zone Method Records

- In many places, no need to pass around the user's original options bag

- In many places, no need to pass around the user's original PlainDate or
  Instant; use epoch nanoseconds, ISO Date Records, and ISO Date-Time
  Records instead

- No more copying the own properties of options bags

- Most of the calendar and time zone operations are now infallible

- The set of extra calendar fields that used to be returned by
  Temporal.Calendar.prototype.fields() is now static; so no need to have
  the complicated PrepareTemporalFields operation that returns a null-
  prototype object with own data properties that correspond to arbitrary
  user fields. Dates in calendar space can be represented by a Calendar
  Fields Record with known fields.

- Much of the special-casing to avoid user calls that was added in #2519
  and similar PRs is now unobservable and is removed.

Closes: #2836
Closes: #2853
Closes: #2854
ptomato added a commit that referenced this issue Sep 5, 2024
This is a very large change, as it not only removes Temporal.Calendar and
Temporal.TimeZone, but also tries to eliminate any extra complexity due to
no longer having to deal with user code calls for calendar and time zone
calculations.

Some of the things that are removed or simplified include:

- No more Calendar Method Records and Time Zone Method Records

- In many places, no need to pass around the user's original options bag

- In many places, no need to pass around the user's original PlainDate or
  Instant; use epoch nanoseconds, ISO Date Records, and ISO Date-Time
  Records instead

- No more copying the own properties of options bags

- Most of the calendar and time zone operations are now infallible

- The set of extra calendar fields that used to be returned by
  Temporal.Calendar.prototype.fields() is now static; so no need to have
  the complicated PrepareTemporalFields operation that returns a null-
  prototype object with own data properties that correspond to arbitrary
  user fields. Dates in calendar space can be represented by a Calendar
  Fields Record with known fields.

- Much of the special-casing to avoid user calls that was added in #2519
  and similar PRs is now unobservable and is removed.

Closes: #2836
Closes: #2853
Closes: #2854
@ptomato ptomato closed this as completed in b889242 Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant