icu4x icon indicating copy to clipboard operation
icu4x copied to clipboard

Consider special-casing year 1906 in the Chinese calendar

Open hsivonen opened this issue 7 months ago • 2 comments
trafficstars

According to https://github.com/dotnet/runtime/blob/1d1bf92fcf43aa6981804dc53c5174445069c9e4/src/libraries/System.Private.CoreLib/src/System/Globalization/ChineseLunisolarCalendar.cs#L34 how the months of the Chinese calendar were actually used in 1906 differs from Reingold's math.

Decide if the calendar offered by ICU4X is meant to match "truth on the ground" on this point, and potentially special-case this.

hsivonen avatar Apr 14 '25 14:04 hsivonen

https://ytliu0.github.io/ChineseCalendar/faq.html indicates that as far as historical accuracy goes, there's much more to resolve than 1906.

hsivonen avatar Apr 15 '25 10:04 hsivonen

Decide if the calendar offered by ICU4X is meant to match "truth on the ground" on this point, and potentially special-case this.

We do intend to match the ground truth. There are potentially issues where there's not a single ground truth but multiple depending on locations/almanacs/etc, where we should be careful.

Manishearth avatar Apr 24 '25 23:04 Manishearth

The official body implementing GB/T 33661-2017 is the Purple Mountain Observatory:

http://www.pmo.cas.cn/xwdt2019/kpdt2019/202203/t20220309_6386774.html

Here is their almanac for 1900 through 2025 in PDF form:

http://www.pmo.cas.cn/xwdt2019/kpdt2019/202203/P020250414456381274062.pdf

The Hong Kong Observatory, while not the officially sanctioned observatory, publishes machine-readable tables following the same algorithm from 1901 to 2100:

https://www.hko.gov.hk/en/gts/time/conversion1_text.htm

I haven't verified yet whether the PMO and HKO almanacs match each other.

I read a copy of GB/T 33661-2017, and it doesn't say a lot that we don't already know, except that it refers to the IERS as the official standard for the astronomical calculations, and says that the calculations must be performed with 1-second accuracy:

https://www.iers.org/IERS/EN/DataProducts/Conventions/conventions.html

sffc avatar Jul 24 '25 22:07 sffc

Manually reading the PMO document, the month start dates from 1900 to 1912 are:

1900:
01-01
01-31 (New Year)
03-01
03-31
04-29
05-28
06-27
07-26
08-25
09-24 (Leap Month)
10-23
11-22
12-22
-
1901:
01-20
02-19 (New Year)
03-20
04-19
05-18
06-16
07-16
08-14
09-13
10-12
11-11
12-11
-
1902:
01-10
02-08 (New Year)
03-10
04-08
05-08
06-06
07-05
08-04
09-02
10-02
10-31
11-30
12-30
-
1903:
01-29 (New Year)
02-27
03-29
04-27
05-27
06-25 (Leap Month)
07-24
08-23
09-21
10-20
11-19
12-19
-
1904:
01-17
02-16 (New Year)
03-17
04-16
05-15
06-14
07-13
08-11
09-10
10-09
11-07
12-07
-
1905:
01-06
02-04 (New Year)
03-06
04-05
05-04
06-03
07-03
08-01
08-30
09-29
10-28
11-27
12-26
-
1906:
01-25 (New Year)
02-23
03-25
04-24
05-23 (Leap Month)
06-22
07-21
08-20
09-18
10-18
11-16
12-16
-
1907:
01-14
02-13 (New Year)
03-14
04-13
05-12
06-11
07-10
08-09
09-08
10-07
11-06
12-05
-
1908:
01-04
02-02 (New Year)
03-03
04-01
04-30
05-30
06-29
07-28
08-27
09-25
10-25
11-24
12-23
-
1909:
01-22 (New Year)
02-20
03-22 (Leap Month)
04-20
05-19
06-18
07-17
08-16
09-14
10-14
11-13
12-13
-
1910:
01-11
02-10 (New Year)
03-11
04-10
05-09
06-07
07-07
08-05
09-04
10-03
11-02
12-02
-
1911:
01-01
01-30 (New Year)
03-01
03-30
04-29
05-28
06-26
07-26 (Leap Month)
08-24
09-22
10-22
11-21
12-20
-
1912:
01-19
02-18 (New Year)
03-19
04-17
05-17
06-15
07-14
08-13
09-11
10-10
11-09
12-09

Tips for future readers:

  • Search for "初一" in the document. It means "first day of the month". From there, the column header is the Gregorian month, and the row header is the Gregorian day.
  • Leap months are indicated with "闰"
  • The new year is indicated with "正月"

After compiling the above dates from the PMO document, I cross-referenced them with the HKO document, and they appear to be identical for the years 1901-1912.

sffc avatar Jul 24 '25 23:07 sffc

According to https://github.com/dotnet/runtime/blob/1d1bf92fcf43aa6981804dc53c5174445069c9e4/src/libraries/System.Private.CoreLib/src/System/Globalization/ChineseLunisolarCalendar.cs#L34 how the months of the Chinese calendar were actually used in 1906 differs from Reingold's math.

Decide if the calendar offered by ICU4X is meant to match "truth on the ground" on this point, and potentially special-case this.

Both PMO and HKO indicate that there was a month starting on 1906-04-24, the 4th month of that year, followed by a leap month starting on 1906-05-23. The HKO document further indicates that a major solar term fell on the last day of the 4th month (1906-05-22) and again on the first day of the 5th month (1906-06-22), thereby causing the month starting on 1906-05-23 to be a leap month.

sffc avatar Jul 24 '25 23:07 sffc

Relevant for this discussion: the PMO document has a forward that states

  1. 解放前编算出版的历书,由于计算条 件 的 限 制,会 出 现 与 现 代 历 书 计 算 模 型 所 推 算 的 日 历 有 日 期 偏 差 的 情 况。但为了保持历书使用的连续性,本历表编制时不予 修 改,即: 1900-1911 年 历 表 以 清 代 出 版 《时 宪 书》为 准, 1912-1948 年历表依据前中央观象台所编《中华民国历书》和前中央研究院所编《国民历》。
  2. 新中国成立后,中国科学院紫金山天文台承担国 家 历 书 编 算 工 作。 本 历 表 1949-2025 年 依 据 的 编 算 模 型 遵 循国家标准《农历的编算和颁行》。
  3. 本历表节气时间系北京时间,均采用现代历书计算模型推算,与旧历书所载有日期偏差的在表中予以标记说明。

Translated by Google Translate:

  1. Due to the limitations of calculation conditions, the calendar compiled and published before liberation will have date deviations from the calendar calculated by the calculation model of modern calendars. However, in order to maintain the continuity of the use of the calendar, this calendar will not be revised during its compilation, namely: The calendar for 1900-1911 is based on the "Shixianshu" published in the Qing Dynasty, The calendar for 1912-1948 is based on the "Republic of China Calendar" compiled by the former Central Observatory and the "National Calendar" compiled by the former Academia Sinica.
  2. After the founding of New China, the Purple Mountain Observatory of the Chinese Academy of Sciences undertook the compilation of the national calendar. The compilation model of this calendar for 1949-2025 complies with the National Standard "Compilation and Promulgation of the Lunar Calendar".
  3. The solar terms in this calendar are based on Beijing time, and are all calculated using the modern calendar calculation model. The deviations from the dates in the old calendar are marked in the table.

The last statement is curious. The deviations appear to be printed as footnotes in the PDF. Here are all of the footnotes I could find:

  • 1912: 旧历书中小雪时间为 11 月 23 日。
  • 1913: 旧历书中秋分时间为 9 月 24 日。
  • 1917: 旧历书中大雪时间为 12 月 7 日。
  • 1923: 旧历书中雨水时间为 2 月 19 日。
  • 1927: 旧历书中白露时间为 9 月 8 日。
  • 1928: 旧历书中夏至时间为 6 月 21 日。

Translated by Google Translate:

  • 1912: The date of Minor Snow in the old calendar is November 23.
  • 1913: The date of Autumnal Equinox in the old calendar is September 24.
  • 1917: The date of Heavy Snow in the old calendar is December 7.
  • 1923: The date of Rain Water in the old calendar is February 19.
  • 1927: The date of White Dew in the old calendar is September 8.
  • 1928: The date of Summer Solstice in the old calendar is June 21.

The words there are all names of various solar terms.

Fortunately, all of these deviations appear to be sufficiently far away from a new moon (at least 3 days away) that they shouldn't affect leap months or new years dates.

sffc avatar Jul 24 '25 23:07 sffc

link https://github.com/unicode-org/icu4x/issues/6492

robertbastian avatar Jul 25 '25 14:07 robertbastian

Belated notes from ICU4X WG, 2025-07-31:

  • @hsivonen For the Chinese lunar calendar in Taiwan, it would be nice to look at sources.
  • @sffc CLDR has the Chinese and Korean lunar calendars but not the Taiwan lunar calendar.
  • @hsivonen We don't need to proactively add the feature. From what Microsoft has done, we can see that Microsoft believes that at least up to 2050, the month and day number are going to agree. What kind of confidence can we gain that going forward, they are going to agree?

sffc avatar Aug 13 '25 04:08 sffc

Reopening this issue to track adding tests for this

sffc avatar Sep 13 '25 00:09 sffc

The Hong Kong Observatory as well as Reingold both think there will be a M11L in 2033. The Purple Mountain Observatory hasn't yet published data. I wanted to check how close the numbers are and whether a rounding error could produce one outcome or the other.

2033-11-22 is unequivocally a new moon (the start of M11), and it unequivocally contains a major solar term. At midnight China time on that day, the sun is at 239.6524 degrees, and at midnight on the next day, the sun is at 240.6628 degrees. The new moon occurs at UTC moment 742499.0689, which is well within the bounds of the day that span from UTC moment 742498.666667 to 742499.666667.

The situation in December is a little closer, but still outside the range of rounding error. At midnight China time on 2033-12-21, the sun is at 269.0767 degrees. At midnight on the next day, the sun is at 270.0953 degrees, so the solar term occurred on that date. Just to verify with a secondary source, the US National Weather Service, which links to data from the US Navy, shows the solstice occurring at 21:46 China time on 2033-12-21. This seems comfortably far enough from midnight to say that the solstice is unambiguously on that day.

The new moon, meanwhile, occurs at 742528.7823 UTC, which lands on 2033-12-22, which spans from 742528.6667 to 742529.6667. The same US Navy web site says that the new moon occurs at 2033 Dec 21 18:46 UTC, which is 02:46 on Dec 22 in China time. This seems comfortably far enough from midnight to say that the new moon is unambiguously on 2033-12-22.

In January, the solar term is on 2034-01-20, when the sun goes from 299.6416 degrees to 300.6599 degrees. The new moon is on that same day, 2025-01-20, at UTC 742558.4178 (2034 Jan 20 10:01 UTC according to the US Navy).

The first month after the winter solstice without a solar term is a leap month.

Therefore, the month spanning from 2033-12-21 to 2034-01-19 has no solar term, so it is a leap month, and it is M11L.

sffc avatar Sep 17 '25 22:09 sffc

What made you check 2033?

robertbastian avatar Sep 18 '25 00:09 robertbastian

See the from_fields PR: there are a couple cases where we have a choice between a reference year in the far past and a reference year in the near future, and we've picked the latter.

Manishearth avatar Sep 18 '25 00:09 Manishearth

The HKO data is correct, it's confirmed by multiple sources. The first ambiguity is 2057-09-29 when the new moon is exactly midnight Beijing time. It's too early to call this one because it depends on future leap seconds.

robertbastian avatar Sep 18 '25 10:09 robertbastian

Please don't mark the comments as off-topic. I posted them here because this is the thread where we have other research into the Chinese calendar algorithms. It serves as a reference if there are any questions about M11L coming soon in 2033.

sffc avatar Sep 18 '25 16:09 sffc

Can you elaborate why your detailed calculations for a year that is not being discussed in this thread, and for which you arrive at the same results as all our sources, are important to share with everyone?

robertbastian avatar Sep 18 '25 17:09 robertbastian

Can you elaborate why your detailed calculations for a year that is not being discussed in this thread, and for which you arrive at the same results as all our sources, are important to share with everyone?

I have a proposal https://github.com/tc39/proposal-temporal/pull/3152 to use 2033 as the reference year for the month M11L in Temporal, and since the data hadn't been published yet by the gold standard PMO, I felt it was responsible for me to share additional evidence, in the form of numeric calculations, that 2033 contains that month and is not likely to be subject to a local authority making a different decision based on rounding errors, since 2033 is still in the future. I used this thread because it is the thread where we had been previously posting detailed information about the GB/T standard and calendar authorities. I changed the title of the thread to reflect this.

sffc avatar Sep 18 '25 21:09 sffc