See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with more than one time zone annotation. These
are not syntactically correct according to the grammar and should be
rejected.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with unrecognized annotations, (i.e., neither
time zone nor calendar), in various combinations with recognized
annotations.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with calendar annotations, with and without the
critical flag, and also a check that the second calendar annotation is
disregarded, as per the IETF draft.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with named and numeric offset time zone
annotations, with and without the critical flag, with various combinations
of Z and offset in front of the annotation.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
This tests the normative change from
https://github.com/tc39/proposal-temporal/pull/2260
which achieved consensus in the July 2022 TC39 meeting.
The return value from a userland getOffsetNanosecondsFor method is no
longer allowed to be exactly one 24-hour day.
This adds tests that validate a user-callable getOffsetNanosecondsFor to
several APIs that didn't test this yet: ZonedDateTime.since/until, and
Calendar.era/eraYear.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2377 which reached
consensus at the September 2022 TC39 meeting.
It changes the order in which observable operations are performed on the
values passed to the ___fromFields methods of Calendar.
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.
As of https://github.com/tc39/proposal-temporal/pull/2219 the object
returned from the PrepareTemporalFields abstract operation should be a
null-prototype object. There are a number of places where this is
observable in one of the calendar's ...FromFields() methods. This adds
tests for this behaviour everywhere it is observable.
This adds tests for https://github.com/tc39/proposal-temporal/pull/2203
which was a normative change that reached consensus in the June 2022 TC39
plenary meeting.
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
ISO strings may separate the time from the date with a case-insensitive T,
or a space. This adds tests to all entry points that take ISO strings, to
ensure that they accept an uppercase T, lowercase T, or space as the time
separator.
These tests are based on the one test for Temporal.PlainDateTime.from that
was already present.
Some of these strings wouldn't have been valid even with a valid year in
them (e.g. strings ending in +01:00[UTC]) so fix up the strings that we
test. While touching these tests, I took the opportunity to regularize
them, and add some missing ones for ISO strings that convert to Calendar
and TimeZone.
Everywhere an ISO string is accepted in Temporal, a seconds value of :60
should always be coerced to :59, because of how leap seconds are handled
in ISO strings.
In property bags, a 'seconds: 60' property is not subject to that rule: it
should be handled according to the overflow option if there is one.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
These tests cover, for every API entry point where a Temporal object is
expected, what happens when a value of a different type is passed in that
can't be converted.
Most entry points can convert a string to the expected Temporal type, and
will do ToString on any non-Object argument, and throw RangeError if the
result isn't a string that's convertible to that Temporal type. ToString
will throw TypeError on a Symbol.
Most entry points also take a property bag, and will throw TypeError if
the property bag doesn't have the required properties.
We also have to test for TimeZone and Calendar what happens if the wrong
type is provided as the value of a 'timeZone' or 'calendar' property in
another property bag, up to one level of nested properties.
Adds tests for conversion of a Number whose corresponding toString() value
is a valid ISO string. For some Temporal types this is possible, with a
number like 20220418.
Especially for Temporal.Calendar, we have to take into account the case
where the number is provided as the value for the 'calendar' property in a
property bag, and the case of up to one level of nested property bag as
well.
Regularizes and expands existing tests for this case.
Where possible, observable calls originating from within Temporal, that
require an options argument, should pass `undefined` as that options
argument, rather than `{}` or `Object.create(null)`.
See tc39/proposal-temporal#1685.
These tests check API entry points that convert strings to
Temporal.PlainDate, with a list of various strings that are all not valid
for that context according to ISO 8601.
https://github.com/tc39/proposal-temporal/issues/1753 records the
consensus reached at the October 2021 TC39 meeting to disallow "-000000"
as an extended year, both in Date.parse and Temporal. This adds tests for
the Temporal part of that.
There were two cases where tests in intl402/ had some duplication of tests
that are in built-ins/ as well. Remove this duplication, and restrict the
intl402/ tests to testing things that can't be tested on all hosts.
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.
Move part of the test of toLocaleString which depends on
15 Amendments to the ECMAScript® 2021 Internationalization API Specification
to intl402. Keep behavior specified in earlier chapters in built-ins
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.
Unfortunately, in #3304 I made a last-minute mistake when I added the
uncallable value to the assertion message, and neglected to test it;
Symbols can't be converted to strings like that, so these tests would
fail. This fixes the assertion messages.
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1829
In a previous version of the specification, there was a fallback to the
intrinsic getOffsetNanosecondsFor when it was undefined.
Philip Chimento
André Bargull
Frank Yung-Fong Tang
Philip Chimento
Aditi
Ms2ger
Jesse Alama
Jesse Alama
Jesse Alama
Frank Yung-Fong Tang