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

Editorial: Use ISO Date and Date-Time Records in more places #2949

Closed
ptomato opened this issue Sep 24, 2024 · 0 comments · Fixed by #3003
Closed

Editorial: Use ISO Date and Date-Time Records in more places #2949

ptomato opened this issue Sep 24, 2024 · 0 comments · Fixed by #3003
Labels
editorial spec-text Specification text involved
Milestone

Comments

@ptomato
Copy link
Collaborator

ptomato commented Sep 24, 2024

Similar to what we did for Duration Records in #2308, go through the spec text and replace long parameter lists of year, month, day, hour, etc. with ISO Date-Time Records or ISO Date Records.

@ptomato ptomato added spec-text Specification text involved editorial labels Sep 24, 2024
@ptomato ptomato added this to the Stage "3.5" milestone Sep 24, 2024
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
In CompareISODate, use two ISO Date Records instead of passing each
component individually. In ISODateSurpasses, the first date does not have
to exist, so rewrite the operation without using CompareISODate and only
take an ISO Date Record for the second parameter.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually, pass a Time Record. The
name is no longer really appropriate, since we are not passing a Temporal
object, so rename it to TimeRecordToString.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually, pass Time Records. The
name is no longer really appropriate, since we are not passing a Temporal
object, so rename it to CompareTimeRecord.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
…rename

Instead of passing each component individually, pass an ISO Date-Time
Record. The name is no longer really appropriate, since we are not passing
a Temporal object, so rename it to ISODateTimeToString.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
…ecord

Instead of individual fields, give ISO Date-Time Record just two fields,
[[ISODate]] and [[Time]]. Since we are passing ISO Date and Time Records
in more places, this is better for readability.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
…nding

Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

The [[Day]] field is ignored.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually. GetUTCEpochNanoseconds is
part of ECMA-262 already, so this requires some <ins> and <del> tags.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.
GetNamedTimeZoneEpochNanoseconds is part of ECMA-262 already, so this
requires some <ins> and <del> tags.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
These are repeated several times now throughout the spec, so abstract them
out for readability.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
For PlainDate, PlainYearMonth, and PlainMonthDay, use an ISO Date Record
in the [[ISODate]] internal slot. For PlainDateTime, use an ISO Date-Time
Record in the [[ISODateTime]] internal slot. For PlainTime, use a Time
Record in the [[Time]] internal slot.

This makes a lot more concise spec text, and probably corresponds better
with how it will be implemented.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
Instead of writing out all the field names, add an abstract operation that
also encapsulates the IsValidTime assertion.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
This is the only place it's called from, and it consolidates operations
that take individual time components.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
This avoids creation of an unobservable Temporal.PlainDateTime object, and
is also simpler to read.

See: #2949
ptomato added a commit that referenced this issue Oct 8, 2024
This fits with the general theme of returning Records instead of Objects,
but also these operations were each only called from one place. So inline
them.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
This is the only place it's called from, and it consolidates operations
that take individual time components.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
This avoids creation of an unobservable Temporal.PlainDateTime object, and
is also simpler to read.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
This fits with the general theme of returning Records instead of Objects,
but also these operations were each only called from one place. So inline
them.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually. Also, remove the "To" from
the name, as it's not a conversion operation.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
In CompareISODate, use two ISO Date Records instead of passing each
component individually. In ISODateSurpasses, the first date does not have
to exist, so rewrite the operation without using CompareISODate and only
take an ISO Date Record for the second parameter.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger added a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually, pass a Time Record. The
name is no longer really appropriate, since we are not passing a Temporal
object, so rename it to TimeRecordToString.

See: #2949

Co-authored-by: Ms2ger <[email protected]>
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually, pass Time Records. The
name is no longer really appropriate, since we are not passing a Temporal
object, so rename it to CompareTimeRecord.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
…rename

Instead of passing each component individually, pass an ISO Date-Time
Record. The name is no longer really appropriate, since we are not passing
a Temporal object, so rename it to ISODateTimeToString.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
…ecord

Instead of individual fields, give ISO Date-Time Record just two fields,
[[ISODate]] and [[Time]]. Since we are passing ISO Date and Time Records
in more places, this is better for readability.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
…nding

Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.

The [[Day]] field is ignored.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually. GetUTCEpochNanoseconds is
part of ECMA-262 already, so this requires some <ins> and <del> tags.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually.
GetNamedTimeZoneEpochNanoseconds is part of ECMA-262 already, so this
requires some <ins> and <del> tags.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
These are repeated several times now throughout the spec, so abstract them
out for readability.

See: #2949
Ms2ger added a commit that referenced this issue Oct 8, 2024
For PlainDate, PlainYearMonth, and PlainMonthDay, use an ISO Date Record
in the [[ISODate]] internal slot. For PlainDateTime, use an ISO Date-Time
Record in the [[ISODateTime]] internal slot. For PlainTime, use a Time
Record in the [[Time]] internal slot.

This makes a lot more concise spec text, and probably corresponds better
with how it will be implemented.

See: #2949

Co-authored-by: Justin Grant <[email protected]>
Co-authored-by: Ms2ger <[email protected]>
Ms2ger added a commit that referenced this issue Oct 8, 2024
Instead of writing out all the field names, add an abstract operation that
also encapsulates the IsValidTime assertion.

See: #2949

Co-authored-by: Ms2ger <[email protected]>
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
This is the only place it's called from, and it consolidates operations
that take individual time components.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
This avoids creation of an unobservable Temporal.PlainDateTime object, and
is also simpler to read.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
This fits with the general theme of returning Records instead of Objects,
but also these operations were each only called from one place. So inline
them.

See: #2949
Ms2ger pushed a commit that referenced this issue Oct 8, 2024
Instead of passing each component individually. Also, remove the "To" from
the name, as it's not a conversion operation.

See: #2949
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

Successfully merging a pull request may close this issue.

1 participant