Ensure Temporal.now.timeZone() returns same time zone as new Date() #519
Comments
|
It's folded into temporal.html because it's so short: https://tc39.es/proposal-temporal/#sec-temporal-now |
sffc
changed the title
|
Got it, thanks. I'll change the scope of this issue to be about ensuring consistency between the two ways of getting the default time zone. Maybe they're already consistent. |
|
One way to do this would be to rewrite LocalTZA() in terms of DefaultTimeZone() and whichever abstract operation we use to implement |
|
This kind of editorial issue seems important to resolve when merging into the main spec at Stage 4. I'm confident that we'll be able to find some kind of wording to ensure this correspondence. |
|
Some preliminary wording was added as part of #1292. It still needs to be iterated on. |
ptomato
added a commit
that referenced
this issue
Apr 14, 2022
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
|
#541 is related to this — my draft solution to that issue brings in AvailableTimeZones from the Intl.Enumeration proposal. Note that it's not sufficient to solve this issue; we still have to connect LocalTZA() as I suggested above. |
This was referenced Apr 26, 2022
ptomato
added a commit
that referenced
this issue
May 4, 2022
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 4, 2022
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 4, 2022
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 5, 2022
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
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 5, 2022
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 5, 2022
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 6, 2022
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 6, 2022
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
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 19, 2022
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
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
May 19, 2022
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
…aultTimeZone The intention of this change is to ensure that it is impossible for Temporal to support a different set of time zones than legacy Date. Technically, legacy Date doesn't "support" any time zones — its data model is the same as Temporal.Instant — but calls like new Date(y, m, d, ...) interpret the given date and time as a local time in the system's current time zone. We need to ensure that this vaguely defined "current time zone" is conceptually the same time zone that Temporal.Now.timeZone() returns. Legacy Date's conversion to and from local times is handled by the LocalTZA abstract operation, which is implementation-defined. The idea here is to push the "implementation-definedness" from LocalTZA on to other abstract operations that are also used by Temporal. We remove LocalTZA everywhere it is used, and instead redefine the UTC, LocalTime, and TimeZoneString abstract operations to get the current time zone from the operation DefaultTimeZone, which is where Temporal gets it as well. We also rewrite these operations to perform the same steps as Temporal when it does the same conversions, only without any observable calls to methods on the Temporal.TimeZone object, and without a disambiguation parameter. (The algorithm is the same as what happens when the disambiguation is set to "compatible", which is the default for reasons of interoperability with legacy Date.) This pushes the "implementation-definedness" from LocalTZA into GetIANATimeZoneOffsetNanoseconds, GetIANATimeZoneEpochValue, and DefaultTimeZone. LocalTZA had a lot of explanatory text, which I've tried to move to other sections where it makes sense to do so. (LocalTZA was weird anyway, it performed totally different functions depending on the value of the _isUTC_ parameter — as you can see from the rewritten versions of LocalTime and UTC.) This should affect absolutely nothing for implementations. It's just a more formal guarantee of what was already stipulated. Closes: #519
ptomato
added a commit
that referenced
this issue
Aug 31, 2022
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
With the addition of DefaultTimeZone to ECMA-262, there should be nothing left to define from this note. Closes: #519
ptomato
added a commit
that referenced
this issue
Oct 11, 2022
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
ptomato
added a commit
that referenced
this issue
Oct 11, 2022
With the addition of DefaultTimeZone to ECMA-262, there should be nothing left to define from this note. Closes: #519
Ms2ger
pushed a commit
that referenced
this issue
Oct 11, 2022
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
With the addition of DefaultTimeZone to ECMA-262, there should be nothing left to define from this note. Closes: #519
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should make the time zone match the system time zone used in legacy Date, so that operations like #515 work as expected.
https://tc39.es/ecma262/#sec-local-time-zone-adjustment
The text was updated successfully, but these errors were encountered: