Repository navigation
Conversation
@dhis2/ui 10.19.0's @dhis2-ui/calendar pinned @dhis2/multi-calendar-dates 2.1.2; 10.19.3 asks for ^3.1.0. The lockfile now has a single copy of the @dhis2/ui packages. The ^10 peer dependency range is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Snapshots getFixedPeriodsOptionsById(...).getPeriods for 13 period types, and PeriodTransfer's default year and period list, for gregory, ethiopian, nepali and islamic, with "now" pinned to three dates. The baseline was taken on @dhis2/multi-calendar-dates 1.3.2. On Node 24 (CLDR 48), 1.3.2's @js-temporal/polyfill 0.4.3 throws "Era am ... was not matched by any era" for every Ethiopian date, so the Ethiopian baseline was captured with that polyfill patched locally. The patch is not committed: the Ethiopian cases fail on 1.3.2 until multi-calendar-dates 3.x, which has the fix, lands in the next commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fixed period lists (getFixedPeriodsOptionsById) and PeriodTransfer's default year now use multi-calendar-dates 3.2.0. Its getNowInCalendar returns a plain object, but analytics only reads .eraYear/.year from it, so no code changes were needed. The lockfile now has a single copy of multi-calendar-dates (3.2.0) and @js-temporal/polyfill (0.5.1). Regression snapshot changes, all intended: - ethiopian: every call threw "Era am ... was not matched by any era" on 1.3.2 with current ICU data (the baseline was captured with the polyfill patched). On 3.2.0 the dates are the same, and period names lose the "AA" (Amete Alem) suffix, which was wrong: the years shown (e.g. 2016) are Amete Mihret years. - nepali: periods ending in 2082 end on the correct day. 1.3.2's month lengths for Nepali year 2082 were wrong; 3.2.0's table matches the published 2082 BS calendar (Ashadh 32 days, Ashwin 31, Magh 29). - gregory and islamic: unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
multi-calendar-dates 3.x leaves eraYear undefined for calendars without eras (e.g. Islamic). || and ?? behave the same here, since eraYear is never 0, but ?? states the intent. Also replaces a comment about a pending Temporal decision, which no longer applies since 3.x doesn't expose Temporal objects. The regression snapshots are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.2.1 only corrects Nepali calendar data (dhis2/multi-calendar-dates#108). The regression snapshots are unchanged: they cover Nepali years 2081-2082, whose data did not change. yarn.lock is deduplicated so @dhis2/ui's ^3.1.0 range also resolves to 3.2.1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
kabaros
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
This migration was guided by the
multi-calendar-dates-upgradeskill (dhis2/ai-devtools#4).Summary
Supersedes #1870 (DHIS2-21183). It makes the same dependency bump, to 3.2.1 instead of 3.0.0, and adds regression snapshots that verify the period lists across calendars. #1870 can be closed in favour of this one.
Bumps
@dhis2/multi-calendar-dates^1.2.2→^3.2.1, and the@dhis2/uidev dependency^10.19.0→^10.19.3. The^10peer range is unchanged.Apps that use analytics' period selectors currently bundle analytics' own multi-calendar-dates 1.3.2 and
@js-temporal/polyfill0.4.3 next to their own 3.x copy. 1.3.2 throwsEra am … was not matched by any erafor every Ethiopian date on current browsers. I swapped this branch's build into maps-app and rebuilt it: its bundle went from three copies (multi-calendar-dates 3.2.1 and 1.3.2, polyfill 0.4.3) to multi-calendar-dates 3.2.1 only.Changes
@dhis2/ui10.19.3 first, since 10.19.0 pinned multi-calendar-dates 2.1.2, then multi-calendar-dates 3.2.1. The lockfile has single copies of multi-calendar-dates (3.2.1) and the polyfill (0.5.1).getNowInCalendar(reading.eraYear/.year) andgenerateFixedPeriods, whose inputs and outputs are unchanged.eraYear || yearis noweraYear ?? year, and an outdated comment about Temporal is replaced.Regression snapshots
PeriodDimension/__tests__/multiCalendarDates.regression.spec.jscoversgetFixedPeriodsOptionsById(...).getPeriodsfor 13 period types, andPeriodTransfer's default year and period list. It runs for gregory, ethiopian, nepali and islamic, with "now" pinned to three dates. The baseline was taken on 1.3.2, in its own commit.AA(Amete Alem) suffix, e.g.Meskerem 2016 AA→Meskerem 2016.Test plan
yarn test(104 suites),yarn lint,yarn buildWarning
Existing bugs, not fixed in this PR (both happen on 1.3.2 as well):
filterFuturePeriodsparses calendar dates withnew Date(). For non-Gregorian calendars it filters the wrong periods: Nepali returns no current-year periods, and Ethiopian and Islamic return future ones.getFixedPeriodsOptionsignores theperiodsSettingsthatPeriodTransferpasses in. The fixed period list is therefore always Gregorian, while the year field uses the server calendar.🤖 Generated with Claude Code