As of https://github.com/tc39/proposal-temporal/pull/2219 the arguments to
the calendar.mergeFields() methods should be null-prototype objects when
called from with() and toPlainDate() methods. This adds tests for that
behaviour.
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.
As of https://github.com/tc39/proposal-temporal/pull/2219 PlainYearMonth's
add() and subtract() methods should be calling the calendar's
yearMonthFromFields() method with a null-prototype object as the options
parameter, due to the change in
AddDurationToOrSubtractDurationFromPlainYearMonth. This adds a test for
this behaviour.
As of https://github.com/tc39/proposal-temporal/pull/2219 since() and
until() methods should be calling the calendar's dateUntil() method with a
null-prototype object as the options parameter, due to the change in
MergeLargestUnitOption. This adds a test for this behaviour.
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.
Each from() method except Calendar and TimeZone should test that when you
pass an instance of that type, the return value is a clone of that
instance, and a distinct object.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
In order to test the referenceISODay of a PlainYearMonth we add an
argument to TemporalHelpers.assertPlainYearMonth.
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.
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.
Add a consistent set of invalid strings for all of the
smallestunit-invalid-string.js and largestunit-invalid-string.js tests:
- "era" and "eraYear" in singular and plural
- all of the units that are disallowed for that particular method call, in
singular and plural
- an allowed unit with \0 at the end
- an allowed unit with an "i" replaced by a dotless i
- an allowed unit but with all-caps
- an unrelated string.
https://github.com/tc39/proposal-temporal/pull/2003 is a normative change
that reached consensus at the March 2022 TC39 plenary meeting. This adds
tests that verify the new spec text is implemented correctly, performing
arithmetic on a PlainYearMonth instance that would previously have thrown
an error if it was implemented as written.
https://github.com/tc39/proposal-temporal/pull/2090 is a normative change
that reached consensus at the March 2022 TC39 plenary meeting. This adds
tests that verify the change made to the formatting of years between 0 and
999 inclusive in all toString and toJSON methods of Temporal types that
can output an ISO year number in their return value.
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.
https://github.com/tc39/proposal-temporal/issues/1910 found a bug in an
indentation level of a line in the Temporal proposal, which affected the
outcome of the PreparePartialTemporalFields abstract operation. This adds
tests for all entry points that use that abstract operation, to make sure
the behaviour is correct: only defined properties are copied in with()
methods.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
These tests already existed for PlainDate. Copy them to the other types
(and use the constructor instead of from() in order to be as simple as
possible)
Some of these (in PlainDate) had already been rewritten to test more
invalid strings that are otherwise valid units. This commit takes these
improvements and brings them to all of the similar tests for other types'
since() and until() methods.
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.
