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.
