Replace the `deepEqual` function with `assert.compareArray` resp.
`verifyProperty`.
Also remove the second part of "sm/strict/15.4.5.1.js", because it's
terribly out-dated w.r.t. the SpiderMonkey implementation of Array
objects.
On engines which pass through these functions to the libc library they can
return slightly different values depending on the OS and archictures.
Showing a few example with Python, which also passes these through to libc on a
few platforms I have access to:
Ubuntu Noble, Python 12, s390x
```
>>> import math
>>> math.cbrt(math.e)
1.3956124250860897
>>> math.acosh(math.cosh(0.2))
0.20000000000000023
```
Ubuntu Noble, Python 12, x86_64
```
>>> import math
>>> math.cbrt(math.e)
1.39561242508609
>>> math.acosh(math.cosh(0.2))
0.20000000000000023
```
MacOS 14, Python 12, x86_64
```
>>> import math
>>> math.cbrt(math.e)
1.3956124250860895
>>> math.acosh(math.cosh(0.2))
0.20000000000000026
```
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.