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

AdjustRoundedDurationDays: CreateDurationRecord is fallible #2536

Closed
anba opened this issue Mar 24, 2023 · 1 comment
Closed

AdjustRoundedDurationDays: CreateDurationRecord is fallible #2536

anba opened this issue Mar 24, 2023 · 1 comment
Assignees
Labels
editorial spec-text Specification text involved
Milestone

Comments

@anba
Copy link
Contributor

anba commented Mar 24, 2023

The adjustedDateDuration and adjustedTimeDuration duration records can have different duration signs, which means the CreateDurationRecord call is fallible.

Test case:

let calendar = new class extends Temporal.Calendar {
  dateAdd(date, duration, options) {
    console.log(`dateAdd(${date}, ${duration})`);
    if (duration.days === 10) {
      return super.dateAdd(date, duration.negated(), options);
    }
    return super.dateAdd(date, duration, options);
  }
}("iso8601");

let zdt = new Temporal.ZonedDateTime(0n, "UTC", calendar);

let d = Temporal.Duration.from({
  days: 10,
  hours: 25,
});

let r = d.round({
  smallestUnit: "nanoseconds",
  roundingIncrement: 5,
  relativeTo: zdt,
});
console.log(r.toString());
@gibson042 gibson042 added spec-text Specification text involved editorial labels Mar 30, 2023
@gibson042 gibson042 added this to the Stage "3.5" milestone Mar 30, 2023
@ptomato ptomato self-assigned this Jan 16, 2024
@ptomato
Copy link
Collaborator

ptomato commented Jan 16, 2024

This will be addressed as part of #2727 (#2727 (comment) is basically about the same problem)

ptomato added a commit that referenced this issue Jan 16, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
ptomato added a commit that referenced this issue Jan 16, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
ptomato added a commit that referenced this issue Jan 16, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
ptomato added a commit that referenced this issue Jan 17, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
ptomato added a commit that referenced this issue Jan 22, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
Ms2ger pushed a commit that referenced this issue Jan 30, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
Ms2ger pushed a commit that referenced this issue Jan 30, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
ptomato added a commit that referenced this issue Jan 31, 2024
This introduces Normalized Time Duration Records, which we use to
encapsulate 96-bit integer operations on duration times. (In the reference
polyfill, the TimeDuration class fulfills the same purpose.) These
operations are specified naively in the mathematical value domain, but can
be changed in a later editorial commit to correspond to how
implementations would write 64+32 bit operations, if we so desire. (The
results must be exactly the same, so that can be decided later, outside of
a TC39 plenary.)

This commit also replaces TotalDurationNanoseconds with
NormalizeTimeDuration, and NanosecondsToDays with
NormalizedTimeDurationToDays. Several operations are changed to return a
Normalized Duration Record, which is a Normalized Time Duration record
combined with a Date Duration Record.

Having already limited time units of durations in the previous commit,
this does not affect any results, nor any existing tests in test262. But I
can't prove conclusively that there isn't some edge case somewhere that
makes this change observable.

(also obsoletes several pre-existing editorial mistakes)
Closes: #2536
Closes: #2638
Closes: #2616
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial spec-text Specification text involved
Projects
None yet
Development

No branches or pull requests

3 participants