getTimeZoneTransition return values should always correspond with UTC
offset transitions, not with time zone metadata changes such as making
DST permanent or updating abbreviation strings.
See: https://github.com/tc39/proposal-temporal/issues/3105
Check that implementations correctly detect time zone transitions that
are close together. Additionally, test startOfDay() since the time zone
transitions in Brazil occur at midnight.
See https://github.com/tc39/proposal-temporal/issues/3110
* Move Map.prototype.getOrInsert tests from staging
* Fix esid and remove noStrict
* Add check for map.get(-0) to append-new-values-normalizes-zero-key.js
These tests are currently being executed in SpiderMonkey as `non262` tests,
and were exported using the `test262-export.py` script. Linting errors
were then corrected.
Changes made to:
- PlainDate
- PlainYearMonth
- ZonedDateTime
- PlainDateTime
- PlainMonthDay
Merged calendar-number.js and calendar-wrong-type.js, due to no special behaviour of number to be tested.
Extracted string tests to calendar-iso-string.js and renamed the file to calendar-invalid-iso-string.js, due to the contents of the file initially testing invalid ISO strings.
Closes#3873
If you have a leap day, such as February 29, and you get input such as
{ monthCode: "M02", day: 30 }, { overflow: "constrain" }, then you want
the day to be constrained to the leap day February 29, not February 28
as the maximum day would be in a common year. Add tests for this case
for each supported calendar.
Add coverage in particular for dateStyle: undefined and timeStyle:
undefined, and for dateStyle applying to PlainMonthDay/PlainYearMonth
which were not tested.
As of the Time Zone Canonicalization proposal which is stage 3, the
original time zone name should be preserved in Intl.DateTimeFormat
.prototype.resolvedOptions.
Add a separate test that uses Temporal.ZonedDateTime.prototype.equals
to test the canonicalization behaviour.
Adds a test that verifies that Intl.supportedValuesOf('timeZones')
includes those timezones those don't correspond to any continent. This
includes the oceanic Etc/* timezones and UTC.
Fixes: https://github.com/tc39/ecma402/issues/778
"islamic" is underspecified because it doesn't include any information
which location and algorithms should be used to approximate new moon
observations. Instead switch to "islamic-tbla".
