Adjust Calendar/prototype/yearMonthFromFields/reference-day.js for alternative implementations

[anba]

• 74dec5b splits "test/intl402/Temporal/Calendar/prototype/yearMonthFromFields/reference-day.js" into three files, so implementation don't have to skip the whole test when they don't implement a specific calendar.
• 4785479 adjusts the Chinese calendar test to allow ICU4X-based implementations to pass the test.
  • The Chinese calendar doesn't have a well-defined "epoch year". ICU4X uses 2637 BCE as the start of the "epoch year". See also https://docs.rs/icu/latest/icu/calendar/chinese/struct.Chinese.html#year-and-era-codes.
  • ICU4C and ICU4X don't always agree on which years are leap years. Change the related year of "M01L" from 2148 to 1651, and for "M11L" from 2033 to 1517 to use years which work in both ICU4C and ICU4X. ICU4C and ICU4X don't agree on any year which uses "M12L", so we have to delete this entry.

[ptomato]

Agreed 100% on the splitting.

Re. M12L, see https://unicode-org.atlassian.net/browse/ICU-22230. It's unfortunate that we have to do this, but as you say, we would need to understand why implementations differ on this point and find an authoritative source.

cc @FrankYFTang @justingrant @sffc who may be interested.

[anba]

Re. M12L, see https://unicode-org.atlassian.net/browse/ICU-22230. It's unfortunate that we have to do this, but as you say, we would need to understand why implementations differ on this point and find an authoritative source.

Comparing ICU4X (through in-progress Temporal patches for SM) and ICU4C (through the spec polyfill), there appear to be four cases where ICU4X and ICU4C don't agree on leap months in the years 1900...2100. (Years too much in the past/future are probably not worth worrying about.)

Year	ICU4X	ICU4C
1917	M02L	M03L
1922	M05L	M06L
1987	M06L	M07L
2033	M07L	M11L

https://www.hko.gov.hk/en/gts/time/conversion.htm agrees with the ICU4X results for 1917, 1922, and 1987, but for 2033 it agrees with ICU4C. [1]

The conversion tables are provides as pdf-files (e.g. https://www.hko.gov.hk/tc/gts/time/calendar/pdf/files/1987.pdf) and text-files (e.g. https://www.hko.gov.hk/en/gts/time/calendar/text/files/T1987e.txt).

(I didn't find conversion tables issued by the Purple Mountain Observatory, so hopefully the data from the Hong Kong Observatory matches what's issued by PMO.)

[1] https://ytliu0.github.io/ChineseCalendar/index.html?y=2033 also computes M11L for 2033.

[anba]

https://www.xirugu.com/CHI500/Dates_Time/Chinesecalender.pdf also mentions that 2033 is a special-case, see section §4.4 "Why is 2033 an exceptional year?". That might explain the ICU4X results.

[anba]

Can this PR get merged, so I can prepare some follow-up changes to update tests to allow alternative era strings? Thanks!

[justingrant]

Note that @ptomato is out on vacation this week.

[anba]

Note that @ptomato is out on vacation this week.

The PR is already approved, it just needs someone with commit access to merge the changes.

[justingrant]

@Ms2ger would you be able to help merge this?

@anba, looks like a rebase is needed.