expected-failures.txt

####################################################################################################
# SHORTCOMING IN TESTS
####################################################################################################
# TODO: open PRs
#
# built-ins/Temporal/Duration/compare/argument-duration-out-of-range.js (line ~65)
# ::compare not given relativeTo, so will throw RangeError even if behavior not implemented
#
# built-ins/Temporal/PlainDate/prototype/since/wrapping-at-end-of-month.js (line ~92)
# "Dec 30th 1970 to Apr 30th 1973 is 27 months, 30 days, not 28 months" // typo! Dec 31st

####################################################################################################
# SPEC BUGS
####################################################################################################

# SPEC-BUG
# PR: https://github.com/tc39/proposal-temporal/pull/2760 (ptomato)
# Test PR: https://github.com/tc39/test262/pull/4012
# Test Branch: https://github.com/ptomato/test262/tree/temporal-2760
# Test Diff: https://github.com/tc39/test262/pull/4012/files
#
# "Tests for correct intermediate value in ZonedDateTime difference/rounding"

# SPEC-BUG
# Ticket: https://github.com/tc39/proposal-temporal/issues/2742
# PR: https://github.com/tc39/proposal-temporal/pull/2758 (ptomato)
#
# "Fix Duration rounding relative to ZonedDateTime"
# (refactors Duration::round/total to be more DRY with since/until)
#
intl402/Temporal/Duration/prototype/round/relativeto-string-datetime.js
built-ins/Temporal/Duration/prototype/round/timezone-getpossibleinstantsfor-iterable.js
built-ins/Temporal/Duration/prototype/total/precision-exact-mathematical-values-4.js
#
# The mock doesn't expect consecutive calls to getPossibleInstantsFor,
# which the new Duration::round/total algorithm has
built-ins/Temporal/Duration/prototype/total/precision-exact-mathematical-values-3.js
#
# When Duration::round() stops using NormalizedTimeDurationToDays, because of consolidation,
# consecutive conflicting calls to getPossibleInstantsFor won't be policed in the same way
built-ins/Temporal/Duration/prototype/round/relativeto-zoneddatetime-normalized-time-duration-to-days-range-errors.js
built-ins/Temporal/Duration/prototype/total/relativeto-zoneddatetime-normalized-time-duration-to-days-range-errors.js
built-ins/Temporal/Duration/prototype/round/date-and-time-durations-opposite-signs.js
built-ins/Temporal/Duration/prototype/round/normalized-time-duration-to-days-loop-arbitrarily.js
#
# Above PR also refactors other diffing, and cuts out certain uses of NormalizedTimeDurationToDays,
# which changes how consecutive conflicting calls to getPossibleInstantsFor are policed
built-ins/Temporal/ZonedDateTime/prototype/since/normalized-time-duration-to-days-loop-arbitrarily.js
built-ins/Temporal/ZonedDateTime/prototype/until/normalized-time-duration-to-days-loop-arbitrarily.js
built-ins/Temporal/ZonedDateTime/prototype/since/normalized-time-duration-to-days-range-errors.js
built-ins/Temporal/ZonedDateTime/prototype/until/normalized-time-duration-to-days-range-errors.js

# SPEC-BUG
# Ticket: https://github.com/tc39/proposal-temporal/issues/2792
# Test Branch: https://github.com/fullcalendar/test262/tree/temporal-fewer-calls-rounding-rel
# Test Diff: https://github.com/tc39/test262/compare/main...fullcalendar:test262:temporal-fewer-calls-rounding-rel
#
# Our onion-shell rounding algorithm results in fewer calls to dateAdd/dateUntil.
# One likely reason: we short-circuit if the direction of rounding is not outward.
# Ref polyfill seems to retread a lot of ground:
# RoundDuration + (BalanceTimeDuration/AdjustRoundedDurationDays) + BalanceDateDurationRelative
#
# In addition to contents of Test Branch:
# (they police conflicting consecutive calls to dateUntil, but there's only 1 now)
built-ins/Temporal/ZonedDateTime/prototype/since/date-and-time-durations-opposite-signs.js
built-ins/Temporal/ZonedDateTime/prototype/until/date-and-time-durations-opposite-signs.js
# (similar policing concept but with dateAdd)
built-ins/Temporal/PlainDateTime/prototype/since/result-mixed-sign.js
built-ins/Temporal/PlainDateTime/prototype/until/result-mixed-sign.js

# SPEC-BUG
# Ticket: https://github.com/tc39/proposal-temporal/issues/2791
# Test Branch: https://github.com/fullcalendar/test262/tree/temporal-fewer-calls-rounding-day-pd
# Test Diff: https://github.com/tc39/test262/compare/main...fullcalendar:test262:temporal-fewer-calls-rounding-day-pd
#
# CalendarRecord's dateAdd/(dateUntil?) methods are plucked but never used because
# are (unit<=day && relativeTo:PlainDateTime) || (unit<day && relativeTo:ZonedDateTime)
# Just don't pluck it.

# Combination of problems
# Best to triage these after other PRs merged
built-ins/Temporal/ZonedDateTime/prototype/since/order-of-operations.js
built-ins/Temporal/ZonedDateTime/prototype/until/order-of-operations.js
built-ins/Temporal/Duration/prototype/round/order-of-operations.js
built-ins/Temporal/Duration/prototype/total/order-of-operations.js
built-ins/Temporal/Duration/compare/order-of-operations.js
#
# Why discrepancy between add/subtract
built-ins/Temporal/Duration/prototype/add/order-of-operations.js
#built-ins/Temporal/Duration/prototype/subtract/order-of-operations.js

# SPEC-BUG
# Ticket: https://github.com/tc39/proposal-temporal/issues/2790
# PR: https://github.com/tc39/proposal-temporal/pull/2797
# Test Branch: https://github.com/fullcalendar/test262/tree/temporal-fewer-calls-rounding-time-zdt (WIP!)
# Test Diff: https://github.com/tc39/test262/compare/main...fullcalendar:test262:temporal-fewer-calls-rounding-time-zdt
#
# It's not necessary to compute hours-in-day when rounding time parts.
# (hours-in-day needs 2 extra getPossibleInstantsFor calls)
# More importantly, results in a bug (see Ticket)

# SPEC-BUG
# PR: https://github.com/tc39/proposal-temporal/pull/2789
# Test Branch: https://github.com/fullcalendar/test262/tree/temporal-fewer-calls-offset-prefer-reject
# Test Diff: https://github.com/tc39/test262/compare/main...fullcalendar:test262:temporal-fewer-calls-offset-prefer-reject
#
# Instant disambiguation with refer/reject of multiple results from
# getPossibleInstantsFor() can avoid a call to getOffsetNanosecondsFor
# by deriving each candidate's offset by comparing it to the UTC-zoned y/m/d/etc
#
# In addition to contents of Test Branch:
built-ins/Temporal/ZonedDateTime/prototype/round/getoffsetnanosecondsfor-maximum-forward-offset-shift.js

# SPEC-BUG
# Ticket: TODO!
#
# PlainDateTime::toLocaleString should not be swayed by timeZone in any way
#
staging/Intl402/Temporal/old/datetime-toLocaleString.js

# SPEC-BUG
# "Duration::total incorrect result with DST"
# https://github.com/tc39/proposal-temporal/issues/2817

# TODO: review and report our algorithms that are more efficient than ref polyfill
# - native-internal YMD diffing
#   - ours doesn't use loops. faster?
#   - ours is generalized for ISO and Intl. smaller code size
# - code smell in ref polyfill
#   - NanosecondsToDays
#   - NormalizedTimeDurationToDays (related to #2758)
#   - UnbalanceDateDurationRelative
#     (in #2758, no longer used for Duration::round/total, just for Duration::compare)

####################################################################################################
# PRECISION
####################################################################################################

# PRECISION
# We do not "perform long division to calculate the fractional part of the quotient
# remainder / n with more accuracy than 64-bit floating point division" because we don't
# use bigint, and even if we did, it's overly tedious to do string manipulation to simulate this
built-ins/Temporal/Duration/prototype/total/precision-exact-mathematical-values-6.js

# PRECISION (TimeZone subclass/protocol only)
# we don't support hours-in-day greater than 10000000xxx (line 119 in the test),
# which can happen if 1-day-apart TimeZone::getPossibleInstantsFor calls give results wildly apart.
# results in slightly-less-precise-than-desirable (already ridiculous) .hoursInDay values
# this happens because we don't leverage bigint for such normally-simple operations
built-ins/Temporal/ZonedDateTime/prototype/hoursInDay/precision-exact-mathematical-values.js
#
# similar, but with floating point imprecision
built-ins/Temporal/ZonedDateTime/prototype/hoursInDay/precision-exact-mathematical-values-2.js

####################################################################################################
# BAG STUFF
####################################################################################################

# CALLING
# Ticket: https://github.com/tc39/proposal-temporal/issues/2788
# Test Branch: TODO!
#
# A ZonedDateTime should only need to call its timeZone's getOffsetNanosecondsFor
# once during its existence and then cache the resulting ISO values.
#
built-ins/Temporal/ZonedDateTime/prototype/withPlainDate/order-of-operations.js

# CALLING
# Conversion from ZonedDateTime -> PlainYearMonth/PlainMonthDay is supposed to
# create an intermediate PlainDateTime which is then given to Calendar::monthFromFields.
# Instead, we pass the ZonedDateTime directly to Calendar::monthFromFields to prevent
# from needing to make an intermediate object. Also better for code compactness
# because, if we created an intermediate IsoFields with zonedEpochSlotsToIso,
# there's no convenient way to compute all calendar-based fields like year/month/day/etc.
#
# TODO: report this, citing that if the ZonedDateTime fields are already cached,
# then fewer operations (https://github.com/tc39/proposal-temporal/issues/2788).
#
built-ins/Temporal/ZonedDateTime/prototype/toPlainMonthDay/order-of-operations.js
built-ins/Temporal/ZonedDateTime/prototype/toPlainYearMonth/order-of-operations.js

# CALLING
# ZonedDateTime is supposed to create an intermediate PlainDateTime which is then
# given to Calendar::mergeFields. Instead, we pass the ZonedDateTime directly
# to Calendar::mergeFields to prevent from needing to make an intermediate object.
# Also better for code compactness because, if we created intermediate IsoFields
# with zonedEpochSlotsToIso, there's no convenient way to compute all calendar-based
# fields like year/month/day/etc.
#
# TODO: report this, citing that if the ZonedDateTime fields are already cached,
# then fewer operations (https://github.com/tc39/proposal-temporal/issues/2788).
#
built-ins/Temporal/ZonedDateTime/prototype/with/order-of-operations.js

# CALLING
# PlainDateTime::with is supposed to access *time* parts via internal slots.
# We treat the current PlainDateTime as a bag and access the time parts as normal properties,
# Better for code compactness, though a bit slower
built-ins/Temporal/PlainDateTime/prototype/with/order-of-operations.js

####################################################################################################
# MISC NON-COMPLIANT ACCESS (slightly different algos for code size)
####################################################################################################

# CALLING
# Test Branch: https://github.com/fullcalendar/test262/tree/temporal-more-calls-calendar-bag
# Test Diff: https://github.com/tc39/test262/compare/main...fullcalendar:test262:temporal-more-calls-calendar-bag
#
# We pluck the CalendarRecord once for bag-refining and once for MarkerSystem
# creation. Works out well with code reuse the ref impl does it in one pass.
built-ins/Temporal/Duration/compare/order-of-operations.js
#TODO: move this over

# CALLING
# In the spec, `AddDuration` adds dur0 y/m/w/d, then dur1 y/m/w/d, then combines and adds time parts.
# Our version uses two `moveDateTime` calls for better code reuse, which results in:
#   +dur0.timeparts +dur0.ymwd +dur1.timeparts +dur1.ymwd
# Same ultimate results but different calls to Calendar::dateAdd w/ different intermediate durations.
built-ins/Temporal/Duration/prototype/subtract/calendar-dateadd.js

# CALLING
# Discussion: https://github.com/tc39/proposal-temporal/issues/2794
#
# Our algorithm leverages Calendar::day instead of Calendar::fields/dateFromFields
# to get the PlainYearMonth to start-of-month for add/subtract/until/since.
# Better for tree-shaking for the fns api.
#
# Despite the risk of ICU creating new historic calendars with skipped days.
# (see note in intlMath.ts)
#
# TODO: make a calendar whitelist to fail on creation of these new calendars.
# (Leverage what's in calendarConfig.ts)
#
built-ins/Temporal/PlainYearMonth/prototype/since/calendar-datefromfields-called-with-options-undefined.js
built-ins/Temporal/PlainYearMonth/prototype/since/calendar-fields-iterable.js
built-ins/Temporal/PlainYearMonth/prototype/since/calendar-fromfields-called-with-null-prototype-fields.js
built-ins/Temporal/PlainYearMonth/prototype/since/order-of-operations.js
built-ins/Temporal/PlainYearMonth/prototype/until/calendar-datefromfields-called-with-options-undefined.js
built-ins/Temporal/PlainYearMonth/prototype/until/calendar-fields-iterable.js
built-ins/Temporal/PlainYearMonth/prototype/until/calendar-fromfields-called-with-null-prototype-fields.js
built-ins/Temporal/PlainYearMonth/prototype/until/order-of-operations.js
built-ins/Temporal/PlainYearMonth/prototype/add/order-of-operations.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/order-of-operations.js
built-ins/Temporal/PlainYearMonth/prototype/add/calendar-datefromfields-called.js
built-ins/Temporal/PlainYearMonth/prototype/add/calendar-fromfields-called-with-null-prototype-fields.js
built-ins/Temporal/PlainYearMonth/prototype/add/calendar-yearmonthfromfields-called-with-null-prototype-options.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/calendar-datefromfields-called.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/calendar-fromfields-called-with-null-prototype-fields.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/calendar-yearmonthfromfields-called-with-null-prototype-options.js
built-ins/Temporal/PlainYearMonth/prototype/add/end-of-month-out-of-range.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/end-of-month-out-of-range.js
built-ins/Temporal/PlainYearMonth/prototype/add/calendar-fields-iterable.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/calendar-fields-iterable.js
built-ins/Temporal/PlainYearMonth/prototype/add/constructor-in-calendar-fields.js
built-ins/Temporal/PlainYearMonth/prototype/add/duplicate-calendar-fields.js
built-ins/Temporal/PlainYearMonth/prototype/add/proto-in-calendar-fields.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/constructor-in-calendar-fields.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/duplicate-calendar-fields.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/proto-in-calendar-fields.js
built-ins/Temporal/PlainYearMonth/prototype/add/calendar-arguments.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/calendar-arguments.js
built-ins/Temporal/PlainYearMonth/prototype/add/calendar-arguments-extra-options.js
built-ins/Temporal/PlainYearMonth/prototype/add/overflow-wrong-type.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/calendar-arguments-extra-options.js
built-ins/Temporal/PlainYearMonth/prototype/subtract/overflow-wrong-type.js

####################################################################################################
# OBJECTS GIVEN TO PROTOCOLS
####################################################################################################

# CALLING
# getPossibleInstantsFor wants plainDateTimes that sometimes have calendar. instead, always give iso
built-ins/Temporal/PlainDate/prototype/toZonedDateTime/timezone-getpossibleinstantsfor.js

# CALLING
# when ZonedDateTime needs to query Calendar, should give PlainDateTime instead of PlainDate
built-ins/Temporal/ZonedDateTime/prototype/day/custom.js
built-ins/Temporal/ZonedDateTime/prototype/dayOfWeek/custom.js
built-ins/Temporal/ZonedDateTime/prototype/dayOfYear/custom.js
built-ins/Temporal/ZonedDateTime/prototype/daysInMonth/custom.js
built-ins/Temporal/ZonedDateTime/prototype/daysInWeek/custom.js
built-ins/Temporal/ZonedDateTime/prototype/daysInYear/custom.js
built-ins/Temporal/ZonedDateTime/prototype/inLeapYear/custom.js
built-ins/Temporal/ZonedDateTime/prototype/month/custom.js
built-ins/Temporal/ZonedDateTime/prototype/monthCode/custom.js
built-ins/Temporal/ZonedDateTime/prototype/monthsInYear/custom.js
built-ins/Temporal/ZonedDateTime/prototype/year/custom.js
built-ins/Temporal/ZonedDateTime/prototype/yearOfWeek/custom.js

# CALLING
# problem with our adapter needing specific instance of Temporal object
built-ins/Temporal/Duration/compare/calendar-dateadd-called-with-plaindate-instance.js
built-ins/Temporal/PlainDate/prototype/add/custom.js
built-ins/Temporal/PlainDate/prototype/day/custom.js
built-ins/Temporal/PlainDate/prototype/dayOfWeek/custom.js
built-ins/Temporal/PlainDate/prototype/dayOfYear/custom.js
built-ins/Temporal/PlainDate/prototype/daysInMonth/custom.js
built-ins/Temporal/PlainDate/prototype/daysInWeek/custom.js
built-ins/Temporal/PlainDate/prototype/daysInYear/custom.js
built-ins/Temporal/PlainDate/prototype/inLeapYear/custom.js
built-ins/Temporal/PlainDate/prototype/month/custom.js
built-ins/Temporal/PlainDate/prototype/monthCode/custom.js
built-ins/Temporal/PlainDate/prototype/monthsInYear/custom.js
built-ins/Temporal/PlainDate/prototype/since/calendar-dateadd-called-with-plaindate-instance.js
built-ins/Temporal/PlainDate/prototype/subtract/custom.js
built-ins/Temporal/PlainDate/prototype/since/custom.js
built-ins/Temporal/PlainDate/prototype/until/calendar-dateadd-called-with-plaindate-instance.js
built-ins/Temporal/PlainDate/prototype/until/custom.js
built-ins/Temporal/PlainDate/prototype/weekOfYear/custom.js
built-ins/Temporal/PlainDate/prototype/with/custom.js
built-ins/Temporal/PlainDate/prototype/year/custom.js
built-ins/Temporal/PlainDate/prototype/yearOfWeek/custom.js
built-ins/Temporal/PlainDateTime/prototype/day/custom.js
built-ins/Temporal/PlainDateTime/prototype/dayOfWeek/custom.js
built-ins/Temporal/PlainDateTime/prototype/dayOfYear/custom.js
built-ins/Temporal/PlainDateTime/prototype/daysInMonth/custom.js
built-ins/Temporal/PlainDateTime/prototype/daysInWeek/custom.js
built-ins/Temporal/PlainDateTime/prototype/daysInYear/custom.js
built-ins/Temporal/PlainDateTime/prototype/inLeapYear/custom.js
built-ins/Temporal/PlainDateTime/prototype/month/custom.js
built-ins/Temporal/PlainDateTime/prototype/monthCode/custom.js
built-ins/Temporal/PlainDateTime/prototype/monthsInYear/custom.js
built-ins/Temporal/PlainDateTime/prototype/toZonedDateTime/plain-custom-timezone.js
built-ins/Temporal/PlainDateTime/prototype/weekOfYear/custom.js
built-ins/Temporal/PlainDateTime/prototype/year/custom.js
built-ins/Temporal/PlainDateTime/prototype/yearOfWeek/custom.js
built-ins/Temporal/ZonedDateTime/prototype/weekOfYear/custom.js
built-ins/Temporal/PlainYearMonth/prototype/daysInMonth/custom.js
built-ins/Temporal/PlainYearMonth/prototype/daysInYear/custom.js
built-ins/Temporal/PlainYearMonth/prototype/inLeapYear/custom.js
built-ins/Temporal/PlainYearMonth/prototype/month/custom.js
built-ins/Temporal/PlainYearMonth/prototype/monthCode/custom.js
built-ins/Temporal/PlainYearMonth/prototype/monthsInYear/custom.js
built-ins/Temporal/PlainYearMonth/prototype/year/custom.js
built-ins/Temporal/PlainMonthDay/prototype/day/custom.js
built-ins/Temporal/PlainMonthDay/prototype/monthCode/custom.js
built-ins/Temporal/TimeZone/prototype/getPlainDateTimeFor/custom-timezone.js
built-ins/Temporal/Duration/prototype/add/calendar-dateadd-called-with-plaindate-instance.js
built-ins/Temporal/Duration/prototype/subtract/calendar-dateadd-called-with-plaindate-instance.js
built-ins/Temporal/Duration/prototype/total/calendar-dateadd-called-with-plaindate-instance.js
built-ins/Temporal/Duration/prototype/round/calendar-dateadd-called-with-plaindate-instance.js

####################################################################################################
# Intl
####################################################################################################
# NOTE: more in expected-failures-node-gte16.txt

# NOT-IMPLEMENTED
# TimeZone ID canonicalization for Intl.DateTimeFormat
# Polyfilling this is hard for format/formatToParts. The reference-polyfill doesn't even do it.
# The reference-polyfill DOES polyfill resolveOptions (used by tests below), but that will result
# in inconsistent results with format/formatToParts, so best not to polyfill either.
intl402/DateTimeFormat/timezone-case-insensitive.js
intl402/DateTimeFormat/timezone-not-canonicalized.js

# These are caught by the default test glob, but are unrelated to Temporal.
# They rely on Intl.DateTimeFormat supporting offset time zones.
intl402/DateTimeFormat/prototype/format/offset-timezone-gmt-same.js
intl402/DateTimeFormat/prototype/formatToParts/offset-timezone-correct.js
intl402/DateTimeFormat/prototype/resolvedOptions/offset-timezone-basic.js
intl402/DateTimeFormat/prototype/resolvedOptions/offset-timezone-change.js