feat: [DHIS2-18310] enable non-Gregorian calendars in views & lists & forms

[alaa-yahia]

Implements DHIS2-18310 & DHIS2-18311 & DHIS2-18309 & DHIS2-18868

• Modified clientToList, clientToForm and clientToView converters to handle local format conversions (DHIS2-18310)
• Modified FormToClient converter to handle ISO format (DHIS2-18309)
• Ensure that all “Last updated” calculations are working when local calendar is used
• Ensure all date pickers (form and working list) are using local calendar.
• Enable non-Gregorian calendars in working list filters DHIS2-18311
• Fix search for a trackedEntity by a DATETIME & AGE attributes DHIS2-18868

[simonadomnisoru]

Hi @alaa-yahia,
I noticed two issues with the Age field:

1. When selecting a date from the calendar, the year, months, and days are filled with incorrect values. (i.e. In the video below, I selected today's date from the Ethiopian calendar, so the year, months, and day should have been filled with 0).
2. When typing a value into the days field, the calendar is filled with the gregorian value of the date.

Screen.Recording.2024-12-12.at.16.51.40.mov

In the video above I used the Ethiopian calendar. Can you have a look? Thank you!

[JoakimSM]

A good start, but some things we will have to work a bit more on.

In addition to the individual comments we should convert the "last updated" tooltips from ISO to local calendar (I saw this in both the stages and events Widget and the enrollment Widget). Had a very quick look at the stages and events Widget and for now I think you can use something like moment(fromServerDate(updatedAt)).toISOString() and put the result into the clientToView converter of type DATETIME (we should probably also use the serverToClient converter, but this will be checked and resolved in separate ticket)

[JoakimSM]

In addition to other comments:

• We should fix the logic in getDateRangeValidator and getDateTimeRangeValidator. These validators are being used in the search form when using tracked entity attributes of value type date and dateTime. We should replace the parseDate logic and leverage the validation done in the ui library component.
• Don't use parseDate on local dates. I think this means that we should remove parseDate from the codebase in its entirety (I didn't see any valid reason to use it anymore, but let me know if I missed something)

[simonadomnisoru]

Hi @alaa-yahia, I found a few bugs that I hope you can look into. I tested with the Ethiopian and Nepalese calendars. Thank you!

[alaa-yahia]

@simonadomnisoru I've pushed bug fixes addressing your feedbacks. Could you take another look when you have a time?
Thank you

[sonarqubecloud]

Quality Gate failed

Failed conditions
9 New issues
9 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[simonadomnisoru]

@alaa-yahia, fantastic work on this feature! Well done! 🎉