Time zone identifiers supported by ICU, but which aren't valid IANA
identifiers.
Implementations not supporting ECMA-402 are theoretically allowed to
support these identifiers, so the tests have to go into the "intl402"
directory.
Previously, "nested" time zone property bags were unwrapped up to one
level. That is, this object:
{
timeZone: {
// ...Temporal.TimeZone methods
}
}
would not be considered to implement the TimeZone protocol, but would have
its timeZone property used instead, if it were passed to an API that
required a TimeZone protocol object.
These nested property bags are no longer supported. Discussion:
https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753
Corresponding normative PR:
https://github.com/tc39/proposal-temporal/pull/2485
This is the replacement of the old API with the new API, .timeZoneId and
.getTimeZone(). Semantics will be corrected in the following commit.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
This adds several tests for values that should be produced by the time
zone database and should not be subject to change in the future. This
tests basic functionality of TimeZone.getPlainDateTimeFor with an IANA
time zone database.
Aside from the ones that were already tested in etc-timezones.js, this
adds a test for other IANA legacy names.
Previously these were supported in the TimeZone constructor, but not in
from().
See https://github.com/tc39/proposal-temporal/pull/2292 which is a
normative change that achieved consensus at the July 2022 TC39 meeting.
The Etc/GMT±... time zones should be accepted in from() as well as the
TimeZone constructor. Previously this was not the case for +0 and -0 due
to those being IANA legacy names.
This basically copies the existing test file for the TimeZone constructor,
and performs the same tests for TimeZone.from().
See https://github.com/tc39/proposal-temporal/pull/2292 which is a
normative change that achieved consensus at the July 2022 TC39 meeting.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
For cases in the previous commit that actually removed some functionality
from tests in built-ins/, add corresponding tests in intl402/ to preserve
test coverage of that functionality for hosts that do support Intl.
Currently, this test is not conformant to the proposal text.
Temporal.TimeZone.from() calls ToTemporalTimeZone. Since the argument is
a string, we next go to ParseTemporalTimeZone, where on a string such as
`1994-11-05T08:15:30-05:00[UTC]` we would return _result_.[[Name]] (which
would be equal to `UTC`) and discard the UTC offset string.
Philip Chimento
André Bargull
Justin Grant
José Julián Espina
Philip Chimento
Aditi
Jesse Alama
Frank Yung-Fong Tang