search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.98k stars 4.66k forks source link

Chinese Lunisolar Calendar conversion table discrepancy for the year 2057 #107032

Closed elyoh closed 3 weeks ago

elyoh commented 3 weeks ago

Description

There is a data discrepancy in the month structure for the year 2057.

Reproduction Steps

Calculation of the days in lunar months 8 and 9 of the lunisolar year beginning Gregorian 2057 has a data discrepancy.

Expected behavior

Calculation of the days in lunar months 8 and 9 yields 30 and 29 respectively (but see dicussion below).

Actual behavior

Calculation of the days in lunar months 8 and 9 yields 29 and 30 respectively.

Regression?

Possibly. As this is an observational lunisolar calendar, dates of new moons, which determine the lengths of months, can only be predicted for future years, and thus there is no single source of truth.

Known Workarounds

No response

Configuration

No response

Other information

In #10903 and associated PR, data discrepancies for years 2057, 2089 and 2097 were addressed based upon the best available sources at the time, including output from functions defined in Calendrical Calculations (Ultimate Edition). But a subsequent errata provided for the Calendrical Calculation (link) affects the conclusions made about the table entry for Gregorian year 2057. The relevant comment is:

**12. Page 210, last line. In the definition of y2051 in ephemeris-correction (14.15), change the last + sign to -. The difference amounts to almost two minutes in 2051 (the worst case).

Use of the corrected function, gives different lengths for lunar months 8 and 9 in 2057 because the new moon marking the end of lunar month 8 and start of lunar month 9 occurs very close to midnight, and is thus sensitive to the sign error noted. No other entries in the table are affected.

As a side note, an ephemeris-correction function is implemented in .NET too. https://github.com/dotnet/runtime/blob/ef0c712f1ffcc48da481e44fb2981bf4de191eac/src/libraries/System.Private.CoreLib/src/System/Globalization/CalendricalCalculationsHelper.cs#L188 It is based upon an earlier version of Calendrical Calculations which uses an older fitting algorithm, and thus it may be possible for calendars which use this implementation to hit similar discrepancies for dates in the future (PersianCalendar).

dotnet-policy-service[bot] commented 3 weeks ago

Tagging subscribers to this area: @dotnet/area-system-globalization See info in area-owners.md if you want to be subscribed.

huoyaoyuan commented 3 weeks ago

Can we improve the process to update the calander data? It needs to be recalibrated based on astronomical observations due to being three-body system.

tarekgh commented 3 weeks ago

@elyoh are you interested in submitting another PR to fix this issue?