In the AO DisambiguatePossibleInstants, a PlainDateTime instance is passed
to user code. This instance should have the built-in ISO 8601 calendar.
Here are some tests that ensure it does.
See tc39/proposal-temporal#2671.
In PlainYearMonth arithmetic, we need to find the end of the month when
adding a negative duration or subtracting a positive one. This end of the
month can be out of range.
Test case based on one provided by Anba. See issue:
https://github.com/tc39/proposal-temporal/issues/2700
Two issues:
1. There was a typo, the first `gen` should have been `genFn`.
2. And the last `toString` result should be `'[object Generator]'`,
because `Object.getPrototypeOf(gen) == genFn.prototype`. And the
`@@toStringTag` property of `genFn.prototype` is inherited from
`Generator.prototype[@@toStringTag]`.
That also means the "iterator-helpers" flag isn't needed for this test.
For the statement level test, the inner class name is not initialized
at the time the decorators evaluate, resulting in a ReferenceError
that the declaration can not be accessed prior to initialization.
Similar, non-decorator code, like:
class C {
static dec() {}
static {
this.x = C.dec();
class C {}
}
}
also results in a ReferenceError.
For the expression level test, the var C is undefined at the time the
decorators are evaluated, resulting in TypeError while trying to access
a member of undefined.
Similar, non-decorator code, like:
var C = class {
static f() {};
static {
this.x = C.f();
}
}
also results in a TypeError.
This removes several loopholes where it was possible to return particular
values from user calls that would cause infinite loops, or calculate
zero-length days.
This allows removing several tests, as calendar.dateAdd() is no longer
called in several places, and it's no longer possible to create a
situation where BigInt arithmetic is observable in NanosecondsToDays.
* Add Tests for ECMA402 PR811
Add tests to check the order of option readings and output
keys in resolvedOptions of Intl.NumberFormat and PluralRules.
* Address reveiw feedback
Hard code the list of property to be inspect for GetOption
Use compareArray
* Update test/intl402/NumberFormat/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/NumberFormat/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/NumberFormat/prototype/resolvedOptions/return-keys-order-default.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/PluralRules/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/PluralRules/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Fix intl402/PluralRules/prototype/resolvedOptions/return-keys-order-default.js
To test all options
* Add more tests
---------
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Test the explicit setting of ignorePunctuation in the option bag
reflect to the value in resolvedOptions() under Thai and
other locales. (Thai is a special case)
Test the behavior of the compare sync with the value of
resolvedOptions().ignorePunctuation
Note the monkeypatch of getPossibleInstantsFor in test/built-ins/Temporal/
TimeZone/prototype/getInstantFor/argument-builtin-calendar-no-array-
iteration.js.
Other than that, all the tests are basically identical.
Adds new tests to order-of-operations.js in Duration.round and
Duration.total, to exercise the code path where previous to this normative
change, relativeTo would have been converted to PlainDate 3x and 2x,
respectively.
This shortcut path now exists in all round(), since(), and until()
operations.
In Instant, PlainDate, PlainDateTime, and PlainTime, the change isn't
observable, so no tests could be added. This adds test coverage for
- Duration.p.round()
- PlainYearMonth.p.since()
- PlainYearMonth.p.until()
- ZonedDateTime.p.round()
- ZonedDateTime.p.since()
- ZonedDateTime.p.until()
As well as a few cases where we are testing that certain calendar methods
get called during a round operation, but previously were doing so with
options that now become a no-op and no longer call those calendar methods.
In those cases, round to 2 ns, rather than 1 ns.
These two can be combined into one test, since they are very similar. This
will allow testing the sample DST time zone as well, which is not yet
tested.
The behavior of `/\p{RGI_Emoji}/v` and other properties of strings depends on the Unicode & Emoji version being used in the JavaScript engine. This patch adds tests verifying new additions to `RGI_Emoji` for each release of the Unicode Emoji standard are correctly matched.
Adds tests that verify that Instant strings cannot include offset time
zone annotations with sub-minute units.
Also removes a few staging test cases that, due to a polyfill bug, were
incorrectly passing.
There was one remaining Temporal test that was parsing an ISO string
with a sub-minute offset into a Temporal.TimeZone. A polyfill bug was
allowing this test case to pass, even though after
tc39/proposal-temporal#2607 it should have failed.
This commit removes the bad test case.
This commit verifies that ISO strings with sub-minute offsets cannot
be parsed into time zone identifiers. This was a change introduced in
the recently-merged tc39/proposal-temporal#2607, but tests for this case
were missing from #3862 (the tests for that PR).
I noticed in codecov results on an unrelated PR that this case wasn't
being tested, so fixing that mistake now.