fix: support non-gregory calendars [DHIS2-17617]

[tomzemp]

Background

This PR adds periods for non-Gregory calendars and updates the date logic throughout the app such that non-Gregorian dates "work" throughout the app to the extent that we can avoid logic problems when working with non-ISO dates.

This addresses the following tickets:

• DHIS2-17617: adds non-ISO periods to selector bar
• DHIS2-17619: reviews date logic throughout the app to function (as much as possible) with non-ISO dates

Additionally the following will be fixed by this PR:

• DHIS2-18057: using correct display name of selected period (based on user's language)
• DHIS2-18031: preventing crashes from languages like pt_BR where java code is invalid format (due to amendment in multi-calendar-dates)

Some common themes

Period generation

• primarily this requires passing calendar to period generation
• this required some fixes in multi-calendar-dates library (hence the dependency bump)

Avoiding use of Date()

• most of our uses of Date initialization was a step in order to then be able to compare dates (e.g. is the period's start date before/after the organisation unit date's opening date).
• I have tried to refactor to keep all dates in their original string (server timezone) form until we actually need to make the comparison.
• I have moved the comparison logic to common functions, this allows us to centralize the logic and make a common implementation for non-Gregorian calendars. For Gregorian/ISO calendars, we can continue using dates, and for non-Gregorian dates, we can probably use string comparisons (needs testing)
• I don't think we need a to do here because the only advantage of not using string comparison is some additional safeguarding against invalid dates, e.g. 2017-13-20 for Ethiopian calendar.

date manipulation

• this is a bit of a subset of the above, but we had a lot of random date manipulation throughout the app (e.g. adding a ms/day to get some actual limit). I first want through and tried to rewrite everything to avoid these approaches (e.g. instead of adding a day to end date to get the next period's start date, I generated the next period and got the actual start date).
• unfortunately with expiryDays, we arguably still do no need to add days to a given date, and we cannot do that for non-Gregorian dates. However, we only currently use this informational purposes at present, so it's not really dire if this functionality doesn't work with non-ISO calendars. To-do: https://dhis2.atlassian.net/browse/LIBS-692

Handling time zones

• the major use of time zone correction logic in the data entry app was to handle the problem where we got the now date (from new Date()) and needed to compare it with a server date. This is now not necessary as we can make use of multi-calendar-dates getNowInCalendar and then get a date/time string that reflects the wall clock time for the server. This allows us to refactor to remove a lot of code we had in the app for this.
• there are a few cases where we still would like to "correct" a server date to client date/time stamp (audits and last updated information), but these cases are limited and I thought it would be easier for us to include the time zone in these cases.

for example:

To-do : https://dhis2.atlassian.net/browse/LIBS-693

relative time

• we use moment's fromNow (replaced with from) for relative time values, which will not work with non-ISO dates, but again, this seems to be functionality that we can drop when calendar is not ISO without major effect (e.g. we can display last updated 2016-13-03 instead of last updated 5 minutes ago with non ISO calendars).

_for example:_ gregory:

ethiopian:

To-do: https://dhis2.atlassian.net/browse/LIBS-691

Testing

I have primarily tested with automated testing by trying to add/expand coverage for any code that is affected by these changes. I have done some light manual testing (e.g. checked that the period generation works okay and that data entry seems to work). It's a bit hard to test some of these things manually as the

[dhis2-bot]

🚀 Deployed on https://pr-397--dhis2-data-entry.netlify.app

[tomzemp]

UPDATE: I spoke with Jan B and he clarified that datetime stamps on the backend are (at least going forward) supposed to be stored and returned in ISO and that the front-end would have responsibility for displaying them in the system's calendar.

Since we have period start/end dates in the non-gregorian calendars, we need to, for example, compare dates between calendars (e.g. check that the org unit closing date (ISO) is after the period end date (ethiopian)).

This also means that some of the assumptions I had about relative time and displaying date/time stamps were not appropriate. I've gone through and refactored and made use of the conversion functions from the multi-calendar-dates conversion functions, so with the most recent commit, there should no longer be anything that is "to do" for non-gregory calendars. I've also created a component DateText to allow us to pass a date stamp and then isolate all the logic for conversion/formatting (I've also added the useTimeZoneConversion hook in that component to correct time differences).

[dhis2-bot]

:tada: This PR is included in version 100.8.3 :tada:

The release is available on:

• AppHub release
• GitHub release

Your semantic-release bot :package::rocket: