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.

Sign up for GitHub

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

Jump to bottom

Require that the set of (built-in) calendars for Temporal equals the set supported by Intl #541

Closed
littledan opened this issue May 2, 2020 · 5 comments · Fixed by #2155
Closed

Require that the set of (built-in) calendars for Temporal equals the set supported by Intl #541

littledan opened this issue May 2, 2020 · 5 comments · Fixed by #2155
Assignees
@ptomato
Labels
spec-text Specification text involved
Milestone
Next

Comments

@littledan
Copy link
Member

Cross-reference: tc39/ecma402#395 (comment)
@littledan littledan changed the title Note that the set of (built-in) calendars for Temporal equals the set supported by Intl Require that the set of (built-in) calendars for Temporal equals the set supported by Intl May 2, 2020
@littledan littledan added this to the Stage 4 milestone May 14, 2020
@littledan
Copy link
Member Author

If we can agree here that they should correspond, I think we can work out the exact spec text to make them correspond when integrating into the main spec text, getting to Stage 4.

@ptomato ptomato mentioned this issue Aug 28, 2020
Closed
@ptomato ptomato mentioned this issue Nov 6, 2020
Closed
@binyamin binyamin mentioned this issue Nov 25, 2020
Open
@ptomato ptomato mentioned this issue Jan 13, 2021
Closed
@ptomato ptomato added the spec-text Specification text involved label Feb 12, 2021
@ptomato ptomato modified the milestones: Stage 4, Stage 3 Conditional Mar 19, 2021
@ptomato ptomato modified the milestones: Stage 3 Conditional, Next May 12, 2021
@ptomato ptomato mentioned this issue Oct 15, 2021
Closed
@ptomato
Copy link
Collaborator

ptomato commented Oct 15, 2021

@FrankYFTang points out that AvailableCalendars would be a great way to solve this cleanly.

@FrankYFTang
Copy link
Contributor

@FrankYFTang points out that AvailableCalendars would be a great way to solve this cleanly.

One issue of using that is that is not yet part of ECMA402 but only part of a Stage 3 proposal. We may need EDITOR's help to figure out how to handle this inter-stage3 ref.

@ljharb
Copy link
Member

ljharb commented Oct 15, 2021

Surely AvailableCalendars can be added editorially - to 262 as well as 402 - without any stage process, and then utilized in both proposals.

ptomato added a commit that referenced this issue Apr 14, 2022
@ptomato
Define IsValidTimeZone in terms of AvailableTimeZones
2b39e3d 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal. Sharing AvailableTimeZones between ECMA-262 and
ECMA-402 should allow us to stipulate that if an implementation supports
any time zone for formatting in Intl.DateTimeFormat, it must support it
for Temporal as well.

Note this is blocked on resolving whether AvailableTimeZones should return
only canonicalized names or also backzone names:
tc39/proposal-intl-enumeration#37

See: #541
See: #519
ptomato added a commit that referenced this issue Apr 14, 2022
@ptomato
Define IsBuiltinCalendar in terms of AvailableCalendars
13dda27 
AvailableCalendars is an abstract operation defined in the
Intl.Enumeration proposal. Sharing AvailableCalendars between ECMA-262 and
ECMA-402 should allow us to stipulate that if an implementation supports
any calendar for formatting in Intl.DateTimeFormat, it must support it
for Temporal as well.

Note this is blocked on resolving whether AvailableCalendars should return
only canonicalized names or also names like `islamicc` (instead of the
canonical `islamic-civil`):
tc39/proposal-intl-enumeration#37

See: #541
@ptomato ptomato self-assigned this Apr 14, 2022
@ptomato
Copy link
Collaborator

ptomato commented Apr 14, 2022

I have a draft for this in https://github.com/tc39/proposal-temporal/compare/541-available-calendars-and-time-zones?expand=1

It brings in the definitions of AvailableTimeZones and AvailableCalendars from the Intl.Enumeration proposal, but slightly reworded so that they make sense as a 262 operation that gets overridden in 402.
It's currently blocked on resolving tc39/proposal-intl-enumeration#37, but this should be the approximate shape of the solution.

@ptomato ptomato mentioned this issue Apr 14, 2022
Closed
ptomato added a commit that referenced this issue Apr 26, 2022
@ptomato
Editorial: Define IsBuiltinCalendar in terms of AvailableCalendars
9fc3031 
AvailableCalendars is an abstract operation defined in the
Intl.Enumeration proposal. Sharing AvailableCalendars between ECMA-262 and
ECMA-402 should allow us to stipulate that if an implementation supports
any calendar for formatting in Intl.DateTimeFormat, it must support it
for Temporal as well.

The operation in the ECMA-402 part may change when it is resolved at some
point whether AvailableCalendars should return only canonicalized names or
also names like `islamicc` (instead of the canonical `islamic-civil`):
tc39/proposal-intl-enumeration#37

Closes: #541
@ptomato ptomato mentioned this issue Apr 26, 2022
Merged
Ms2ger pushed a commit that referenced this issue Apr 27, 2022
@ptomato @Ms2ger
Editorial: Define IsBuiltinCalendar in terms of AvailableCalendars
896b72d 
AvailableCalendars is an abstract operation defined in the
Intl.Enumeration proposal. Sharing AvailableCalendars between ECMA-262 and
ECMA-402 should allow us to stipulate that if an implementation supports
any calendar for formatting in Intl.DateTimeFormat, it must support it
for Temporal as well.

The operation in the ECMA-402 part may change when it is resolved at some
point whether AvailableCalendars should return only canonicalized names or
also names like `islamicc` (instead of the canonical `islamic-civil`):
tc39/proposal-intl-enumeration#37

Closes: #541
ptomato added a commit that referenced this issue May 4, 2022
@ptomato
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
39f890b 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. I have opened an issue for
resolving whether AvailableTimeZones should return only canonicalized
names or also backzone names:
tc39/proposal-intl-enumeration#37

See: #541
See: #519
ptomato added a commit that referenced this issue May 5, 2022
@ptomato
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
def103f 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. I have opened an issue for
resolving whether AvailableTimeZones should return only canonicalized
names or also backzone names:
tc39/proposal-intl-enumeration#37

See: #541
See: #519
ptomato added a commit that referenced this issue May 6, 2022
@ptomato
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
0907d10 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. I have opened an issue for
resolving whether AvailableTimeZones should return only canonicalized
names or also backzone names:
tc39/proposal-intl-enumeration#37

See: #541
See: #519
ptomato added a commit that referenced this issue May 19, 2022
@ptomato
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
e5aa36d 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. I have opened an issue for
resolving whether AvailableTimeZones should return only canonicalized
names or also backzone names:
tc39/proposal-intl-enumeration#37

See: #541
See: #519
ptomato added a commit that referenced this issue May 19, 2022
@ptomato
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
a4ed9e6 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. I have opened an issue for
resolving whether AvailableTimeZones should return only canonicalized
names or also backzone names:
tc39/proposal-intl-enumeration#37

See: #541
See: #519
ptomato added a commit that referenced this issue Aug 31, 2022
@ptomato
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
b1940b6 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. I have opened an issue for
resolving whether AvailableTimeZones should return only canonicalized
names or also backzone names:
tc39/proposal-intl-enumeration#37

See: #541
See: #519
ptomato added a commit that referenced this issue Oct 11, 2022
@ptomato
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
4334433 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. Intl.Enumeration considered
it too risky for their Stage 4 bid to change this, despite being an
unobservable change, so we will have to make changes in ECMA-402 later,
after Intl.Enumeration reaches Stage 4.

See: #541
See: #519
Ms2ger pushed a commit that referenced this issue Oct 11, 2022
@ptomato @Ms2ger
Editorial: Define IsValidTimeZoneName in terms of AvailableTimeZones
d83dcf0 
AvailableTimeZones is an abstract operation defined in the
Intl.Enumeration proposal (though there is a small difference, see below.)
Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us
to stipulate that if an implementation supports any time zone for
formatting in Intl.DateTimeFormat, it must support it for Temporal as
well.

This change means IsValidTimeZoneName is no longer implementation-defined,
and does not need to exist in ECMA-402, only in 262.

Note, this requires a slightly different algorithm for AvailableTimeZones
than the one in the Intl.Enumeration proposal. Intl.Enumeration considered
it too risky for their Stage 4 bid to change this, despite being an
unobservable change, so we will have to make changes in ECMA-402 later,
after Intl.Enumeration reaches Stage 4.

See: #541
See: #519
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ptomato ptomato

Labels
spec-text Specification text involved
Projects
None yet
Milestone
Next
Development

Successfully merging a pull request may close this issue.

Editorial: Define IsBuiltinCalendar in terms of AvailableCalendars tc39/proposal-temporal
4 participants
@ljharb @littledan @ptomato @FrankYFTang