As per the discussion in
https://github.com/tc39/proposal-temporal/issues/2379#issuecomment-1248557100
and the PR https://github.com/tc39/proposal-temporal/pull/2398, which is
to be presented for consensus to TC39 in the upcoming plenary meeting, UTC
offsets and the Z designator should be disallowed after any date-only
strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to
follow a time component. Z remains disallowed in any string being parsed
into a Plain type.
Annotations become allowed after any ISO string, even YYYY-MM and MM-DD
where they were previously disallowed.
The Temporal.Calendar.prototype.daysInMonth() method is observably called
in a few places in the spec. It should be tracked on the object returned
from TemporalHelpers.calendarObserver().
The idea is to deduplicate more string tests into methods on this object,
that return collections of valid and invalid strings. This adds
collections of valid and invalid PlainYearMonth and PlainMonthDay strings.
This tests some of the normative changes in
https://github.com/tc39/proposal-temporal/pull/2245, which achieved
consensus in the July 2022 TC39 meeting, specifically as they apply to
places where the MergeLargestUnitOperation was called.
Due to the use of the pre-existing spec operation CopyDataProperties, the
order of observable property operations has changed from a batch of
[[GetOwnProperty]] followed by a batch of [[Get]], to a series of
interleaved [[GetOwnProperty]]/[[Get]] pairs. This previously wasn't
tested because TemporalHelpers.propertyBagObserver didn't track
[[GetOwnProperty]] operations, but now it does.
Similar to the previous commits with property bags and time zones, there
are also some existing tests that 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, or bugs due to
a Symbol-valued property.
Updates existing tests to use this helper.
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.
Several tests in staging use the Pacific/Apia IANA time zone to test the
behaviour of various algorithms for the case where Samoa skipped the
entire day of Dec. 30, 2011, when they switched from one side of the
International Date Line to the other. Since implementations are not
technically required to support IANA time zones, add a fake Samoa time
zone to TemporalHelpers that has the same transition, and use it in those
tests.
(The time zone isn't exactly the same as Pacific/Apia, since Samoa also
observes DST and this time zone doesn't. It's only the same for this one
transition.)
See: #3649
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.
I've occasionally gotten bugs due to Get or Has operations being performed
on symbol-valued properties, and trying to format them inside backtick
strings, which throws. I've been meaning to consolidate this for a while
into a formatting function which nicely formats any kind of property key.
Now that I'm about to write more tests having to do with order of
observable operations, this seems like a good time to do it.
This is a refactor in temporalHelpers.js.
This adds an object, TemporalHelpers.ISO, which has methods that return
arrays of various ISO strings. The idea is to deduplicate more string
tests into methods on this object.
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.
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.
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.
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.
I made a mistake with one of the signs in one of the time zones that we
use for verifying DST handling. Luckily this didn't affect any previously
existing tests, but it affected some new tests that I'm going to add in
the next commit.
How do I know that _this_ arithmetic is correct? I feel reasonably
confident with the added test.
A follow up to the previous commit, this rewrites some tests that relied
on the lack of brand checks for certain Temporal.TimeZone methods.
https://github.com/tc39/proposal-temporal/pull/1693 added brand checks to
these methods.
We can no longer use a plain object time zone or even a Proxy with a real
branded Temporal.TimeZone object as its handler to do these tests, so we
instead create an instance of Temporal.TimeZone and define own accessor
properties on it in order to test the observable property accesses that we
need to see according to the spec text.
This requires an improvement to TemporalHelpers.observeProperty() in order
to be able to log property accesses to Symbol-valued properties.
I used kind of misleading parameter names in this function, they are not
"one" and "two" of the same thing, but a Temporal.PlainDate and a
Temporal.Duration.
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1873
This adds a new Temporal helper calendar that asserts that its dateAdd()
method is always called with a PlainDate instance. This allows testing
that relativeTo parameters are always converted to PlainDate if they are
not ZonedDateTime and not undefined. Prior to the normative PR, they
would be converted to PlainDateTime instead.
Additionally and optionally, the helper calendar can also assert that its
dateAdd() method is called with a specific PlainDate instance. This allows
testing that the instance is the same PlainDate passed as the relativeTo
parameter (in the case of Duration methods) or is the receiver (in the
case of PlainDate methods). For the PlainDateTime and PlainYearMonth
methods the PlainDate instance is synthesized internally so there is no
need to assert that dateAdd() is called with a specific instance.
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.
* Temporal.now.plainDateTime: import tests from prop
* Add required metadata
* Correct invalid test
Ensure the error is thrown due to the invocation of the provided method.
Add a separate test to verify how the method is invoked.
* Remove duplicated assertions
* Improve coverage
* Rewrite test to focus on Calendar parameter
The observable interactions with the "timeZone" parameter are verified
by another test which is named for that purpose.
* Remove non-standard test
This test's title suggests that it was intended to verify the behavior
when the "calendar" parameter was undefined. The expected behavior in
that case depends on the presence of a builtin calendar named
"undefined." Test262 cannot definitively assert the presence or absence
of such a calendar.
In contrast to the title, the test body actually uses the calendar name
"japanese." Test262 cannot definitively assert the presence or absence
of such a calendar.
Cam Tenny
Philip Chimento
Ms2ger
Philip Chimento
Frank Yung-Fong Tang
jugglinmike