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.
We should make sure that we are providing the correct arguments to these
methods even if they are supposed to throw; they should throw for the
reason we expect, and not because we provided the wrong arguments.
This consolidates the few existing tests for options bags in Temporal
being of the wrong type, and adds them for every entry point in Temporal
that accepts an options bag.
These are mostly identical tests, but there is a variation for methods
like round() where either an options bag or string is accepted.
(Philip, March 2022: This was originally Frank's PR #3057. I did some
reformatting, removed duplicate tests, addressed the review comments that
I left the first time around, and added some cases that I felt were not
yet complete.)
(Philip, March 2022: This was originally Frank's PR #3060. I did some
reformatting, removed a test that didn't exercise the whole feature, and
combined some duplicate tests with some existing tests.)
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/pull/1693 added checks for the
receiver of certain Temporal.Calendar and Temporal.TimeZone methods. Add
branding tests for these methods, similar to the already existing branding
tests.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
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.
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.
* Sync test of Temporal.Calendar.p*.fields to 1750
https://github.com/tc39/proposal-temporal/pull
* add more test
* add more tests for T*.Calendar.p*.fields
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/repeated-throw.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/reverse.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/reverse.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Remove loop
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update long-input.js
* Update repeated-throw.js
* Update reverse.js
* ensure the implementation check the content
make sure the validation does not happen after the looping the generator
* add test to check all valid field value
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
There were a few tests already in the tree that overlapped ones that I
added in the previous commit. I've consolidated these and taken
information from the deleted ones where applicable, and improved on the
autogenerated assertion messages.
This reverts commit b690cb67be9b487eb10156c03e2c00869e88cc9d, reversing
changes made to 50dd431dffe5cf86e9064a652d6b01dbbe542cf0. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
While working on adding the Temporal tests from tc39/proposal-temporal I
noticed that these tests tested the same thing as each of the branding.js
tests in the same directory. This removes the duplicate tests.
