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.
Similar to the previous commit with property bags, many existing tests use
a Proxy to test the order of observable operations which involve user code
passed in as part of a Temporal.TimeZone object. I am going to write
several more tests that do this, as well. This seems like a good thing to
put into TemporalHelpers, where it can be implemented consistently so that
we don't get discrepancies in which operations are tracked.
Updates existing tests to use this helper.
The "half___" modes all round to the nearest increment except when there
is a tie. The previous tests didn't test rounding in the case of any ties
(except for .toString()) so here we use some different numbers in which
there is a tie, in order to make tests where the "half___" modes are more
thoroughly tested.
See https://github.com/tc39/proposal-temporal/pull/2262 which added new
rounding modes from NumberFormat V3.
See https://github.com/tc39/proposal-temporal/pull/2262 which added new
rounding modes from NumberFormat V3.
These tests use the same format as the previous ones. The tests for the
"half" rounding modes aren't very good yet, as they don't show any of the
differences between the tiebreaking schemes; there aren't any ties in the
data to be broken. (Except in .toString().) A subsequent commit will
correct this.
Take all the existing tests for round() calculations using different
rounding modes and standardize them. Add tests for Duration, Instant and
ZonedDateTime, which were still in the old format in staging.
Take all the existing tests for since/until calculations using different
rounding modes and standardize them. Add tests for Instant and
ZonedDateTime, which were still in the old format in staging.
See https://github.com/tc39/proposal-temporal/pull/2262, which reached
consensus in the July 2022 TC39 meeting. This change added several
rounding modes from the NumberFormat V3 proposal, some of which were
listed as invalid in the roundingmode-invalid-string tests. Remove these
items from the list of invalid modes, since they are no longer invalid.
Many existing tests use a Proxy to test the order of observable operations
on a property bag argument that gets passed in to a Temporal API. I am
going to write several more tests that do this, as well. This seems like a
good thing to put into TemporalHelpers, where it can be implemented
consistently so that we don't get discrepancies in which operations are
tracked. (For example, we had some tests which didn't test for an ownKeys
operation that was supposed to be there.)
Updates existing tests to use this helper.
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.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2297 which reached
consensus at the July 2022 TC39 meeting.
Values given as the fractionalSecondDigits option are now truncated to
integers before they are compared to the allowable range.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
This adds tests for a normative change which reached consensus in the June
2022 TC39 meeting, ensuring that the representable range of
Temporal.Instant is always the same regardless of which time zone offset
is used when converting from a string.
See: https://github.com/tc39/proposal-temporal/pull/2189
This adds tests to all entry points where an ISO string is converted to a
Temporal.Instant. The tests exercise various invalid ISO strings to make
sure that they throw a RangeError.
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.
An object may be given in any context where a Temporal.Instant is expected
(see ToTemporalInstant). There is no conversion from a property bag to an
Instant, unlike with other Temporal types. Instead the object is converted
to a string, and if its toString() method yields a valid ISO string, the
conversion succeeds. (An object with the default Object.prototype.toString
will not.)
The round() and toString() methods of Temporal.Instant, PlainDateTime, and
ZonedDateTime can round up or down. However, the instance must not be
treated as "negative" even when the time is before 1 BCE (years are
negative) or before the Unix epoch (epoch nanoseconds are negative). That
is, rounding down is always towards the Big Bang, and rounding up is
always away from it. Add tests that verify this.
This takes the tests of the rounding functionality of
Temporal.PlainTime.p.toString() and adds similar tests covering the
equivalent functionality to Duration, Instant, PlainDateTime, and
ZonedDateTime: all the types that have rounding and precision controls
for how they output their subsecond values.
It also takes the opportunity to improve the existing PlainTime tests:
- fractionalseconddigits-auto.js: More descriptive variable names. Added
assertion messages.
- fractionalseconddigits-number.js: Ditto.
- rounding-cross-midnight.js: Use constructor directly to remove coupling
with from().
- roundingmode-*.js: Add additional tests for specifying the precision
using fractionalSecondDigits.
- smallestunit-fractionalseconddigits.js: Add assertion messages.
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.
Of the toString() methods that have options for printing a time with
seconds and fractional seconds, PlainTime seems to have the most
comprehensive set of tests. Bring all the others (Duration, Instant,
PlainDateTime, and ZonedDateTime) in sync with PlainTime, and edit the
PlainTime ones where necessary to include improvements from the others.
Tests:
- fractionalseconddigits-invalid-string.js: copy and expand on
PlainTime's more comprehensive set of invalid strings. Add assertion
message. Fix front matter.
- fractionalseconddigits-non-integer.js: Fix front matter.
- fractionalseconddigits-out-of-range.js: make sure infinity is tested.
Add assertion messages. Fix front matter.
- fractionalseconddigits-undefined.js: copy PlainTime's more
comprehensive test with whole minutes, whole seconds, and subseconds.
Copy PlainTime's test of an empty function object. Add more
descriptive variable names and assertion messages. Fix front matter.
- fractionalseconddigits-wrong-type.js: inline and delete TemporalHelper
used here; it was only good for this test anyway. Improve assertion
messages.
- smallestunit-valid-units.js: copy PlainTime's test with a second value
with zero seconds even. Refactor repetitive tests into a loop. Copy
the invalid unit "era" from the Instant test. Add assertion messages.
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.
https://github.com/tc39/proposal-temporal/pull/1907 was a bug that caused
negative Duration strings with fractional units to be rounded incorrectly.
Add tests that ensure the rounding mode is correct.
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.
This requires a few adjustments of time zone names and offsets in some
places. The only named time zone that is required to be supported by an
implementation not supporting ECMA-402 is "UTC".
Nails down intended behavior of `PlainDate` and
`PlainDateTime`'s `since` that is already true in the
polyfill but which was specified in a buggy way (and hence
potentially not true in an implementation of Temporal).
Add similar tests for Instant, PlainTime, PlainYearMonth, and
ZonedDateTime.
Reference:
https://github.com/tc39/proposal-temporal/pull/1881
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
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/1875
For convenience, adds some functions to TemporalHelpers to assert that two
Temporal objects are equal, for Duration, Instant, PlainDateTime,
PlainTime, and ZonedDateTime.
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.
Prior to this patch, the modified test invoked the `arrayContains`
utility function without referencing its return value. Unlike Test262's
assertion functions, `arrayContains` does not throw an error when the
expectation is violated, so the prior usage did not influence test
results.
Additionally, the prior version of this test documented incorrect
expectations regarding the expected value produced by the method under
test. Due to the above, these expectations were not enforced.
Correct the test's expectations and enforce those expectations with a
function that will reliably produce an exception if violated.