-
Notifications
You must be signed in to change notification settings - Fork 169
Polyfill fixups for dealing with calendars #3185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This was causing the overflow: "reject" to be ignored in leap month coercion.
These error messages refer to "Chinese year" because they are in the
helperChinese object, but since helperDangi inherits from that it
results in odd error messages. Use ${this.id} instead.
Latest versions of Node have this "Mo" prefix in their ICU data, which completely broke the Chinese and Dangi calendars.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3185 +/- ##
==========================================
- Coverage 96.96% 96.84% -0.13%
==========================================
Files 22 22
Lines 10217 10235 +18
Branches 1841 1841
==========================================
+ Hits 9907 9912 +5
- Misses 261 273 +12
- Partials 49 50 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
The check for the Indian calendar BCE bug included the literal string "Saka", which has been changed to "Śaka" in the latest ICU data. Ignore the formatted era name and just check the formatted date to see if the host is vulnerable to the bug.
justingrant
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, thanks for catching these. I added a few questions, otherwise looks good.
CLDR has removed the "ERA0" code from the Coptic calendar but it looks like they neglected to actually remove the era - if you try to format a date with a negative era year, it prints a positive era year and omits the era code (the final part of formatToParts() is a literal " " part, which normally should be followed by an era part.) Handle this eventuality with a special case.
We need to do the non-negative modulo here, otherwise all negative years are leap years.
80437ef to
5d09e48
Compare
Found these as I wrote tests for Intl Era Monthcode.