The doAsserts is not correct for case like "P100000000000000000000000000Y"
If we test "P100000000000000000000000000Y" because the filed in Duration is only required to
"A float64-representable integer is an integer that is exactly representable as a Number value. That is, for a float64-representable integer x, it must hold that ℝ(𝔽(x)) = x." per
https://tc39.es/proposal-temporal/#sec-properties-of-temporal-duration-instances
The duration it hold may produce string such as
"P99999999999999987584860160Y"
even the test only test the first 10 digits ( log(10^10)/log(2) = 33 bits)
Change the test to test
"P100000000000001000000000000Y" instead, so a negative numerical error will not change the start of the string
from "P1000000000" to "P9999999999"
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.
This adds tests that validate a user-callable getOffsetNanosecondsFor to
several APIs that didn't test this yet: ZonedDateTime.since/until, and
Calendar.era/eraYear.
In order for some tests to ensure that they are testing the right
exception, we need to make sure we are in the path where there are no
possible instants for a particular date-time. Override this method in some
tests.
"15Z" will throw RangeError because Z match
UTCDesignator =>
TimeZoneUTCOffset =>
TimeZoneUTCOffset TimeZoneBracketedAnnotationopt =>
TimeZoneopt
and "15" match
1 DecimalDigit =>
Hour =>
TimeHour =>
TimeSpec
so "15Z" match
TimeSpec TimeZoneopt =>
TimeSpecWithOptionalTimeZoneNotAmbiguous =>
TimeSpecWithOptionalTimeZoneNotAmbiguous Calendaropt =>
CalendarTime =>
TemporalTimeString
Therefore
13.37 ParseTemporalTimeString ( isoString )
https://tc39.es/proposal-temporal/#sec-temporal-parsetemporaltimestring
will succeess in 2. If parseResult is a List of errors, throw a RangeError exception.
but the in step 3
3. If parseResult contains a UTCDesignator Parse Node, throw a RangeError exception.
the "Z" is UTCDesignator so it will throw RangeError.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2377 which reached
consensus at the September 2022 TC39 meeting.
It changes the order in which observable operations are performed on the
values passed to the ___fromFields methods of Calendar.
1. add the test for "seconds"
2. since the default value for "style" is "long", baseStyle for GetDurationUnitOptions is "long" and therefore the
last argument in testOption should be "long"
3. the valid values for "days" does not contains "numeric", and "2-digit". remove them.
4. the valid values for "milliseconds", "microseconds" and "nanoseconds" does not contains "2-digit". remove it.
See https://tc39.es/proposal-intl-duration-format/#table-duration-components about the valid value
notice the last colum is for "Digital Default" while the baseStyle is "digital" but the set up does not set it that way, the default value for "style" is "long" as in
```
13. Let style be ? GetOption(options, "style", "string", « "long", "short", "narrow", "digital" », "long").
```
of https://tc39.es/proposal-intl-duration-format/#sec-Intl.DurationFormat
* Sync to PR 121
Change default from "long" to "short"
Due to the TZDB's recent merging of time zones whose pre-1970 data was
different but post-1970 have been the same, this test is going to start
failing on implementations with up-to-date time zone data (because the
Europe/Amsterdam time zone was absorbed into Europe/Brussels in the latest
update.)
It's on our to-do list to remove all dependencies on IANA time zones from
the Temporal tests in staging/,
(see https://github.com/tc39/test262/issues/3649#issuecomment-1232326175)
but this one is more urgent.
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.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2287 which reached
consensus at the July 2022 TC39 meeting.
It adds tests that ensure that PlainTime strings which require a T
designator for disambiguation, are not disambiguated by adding a calendar
annotation.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2284 which reached
consensus at the July 2022 TC39 meeting.
It adds tests that ensure strings like HHMM-UU[TZ] and HHMMSS[TZ] do not
require a disambiguating T separator, even if HHMM-UU and HHMMSS would by
themselves.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2344 which reached
consensus at the July 2022 TC39 meeting.
It adds a test that catches a corner case in Duration.prototype.round().
For completeness, as we are doing in newer brand checking tests such as
those of Temporal, call these getters with a function object and a bigint
as the receiver.
Suggested in https://github.com/tc39/test262/pull/3614/files#r929662337
Now that we have a staging directory, we can add the old-style tests from
proposal-temporal and avoid having to sync PRs across two repositories
when we convert them to test262 style.
Ms2ger wrote a script to convert them to be executable with the test262
harness, and this is the result of running that script on the remaining
Temporal.Instant tests in proposal-temporal.
More tests of other Temporal types to follow.
The intention of this test is to ensure that all built-in properties of
the global object are also exposed on the ShadowRealm's global object,
without penalizing implementations that don't have all of them
implemented.
Notably, SharedArrayBuffer may still not be (re-)enabled in all
circumstances.
This implements the normative change in
https://github.com/tc39/proposal-temporal/pull/2269 which reached
consensus at the July 2022 TC39 meeting.
There was already a test for PlainDate for this topic, which needs to be
adjusted to accommodate the normative change. Tests for PlainDateTime and
ZonedDateTime did not yet exist, so add new ones based on the PlainDate
test.
Frank Yung-Fong Tang
Philip Chimento
Frank Yung-Fong Tang
Jordan Harband
Justin Ridgewell
polsevev
Philip Chimento
Aditi
Kevin Gibbons
Romulo Cintra
Richard Gibson
Ms2ger
Linus Groh
Yusuke Suzuki
André Bargull