...
In scope of modular implementation in Nepal support for secondary calendar was added. While previous solution allowed to replace one calendar with the other, new solution allows user to easily switch between Gregorian calendar and second calendar of choice.
| Code Block |
|---|
- `secondCalendarFormatting`: formatting options for second calendar (both picker and display), default: "DD-MM-YYYY"
- `secondCalendarFormattingLang`: formatting language for second calendar (when displayed as saved data, not in pickers), default: "en" |
Current implementation will need refactoring if it were to use any other calendar than Nepali. It looks like this:
| Code Block |
|---|
export function formatDateFromISO(mm, intl, date) {
const isSecondaryCalendar = JSON.parse(localStorage.getItem(STORAGE_KEY_SECONDARY_CALENDAR));
if (isSecondaryCalendar) {
const secondCalendarFormatting = mm.getConf("fe-core", "secondCalendarFormatting", DEFAULT_SETTINGS.SECOND_CALENDAR_FORMAT);
const secondCalendarFormattingLang = mm.getConf("fe-core", "secondCalendarFormattingLang", DEFAULT_SETTINGS.SECOND_CALENDAR_LANG);
return neFormateDateFromISO(date, [secondCalendarFormatting, secondCalendarFormattingLang]);
}
return adFormateDateFromISO(mm, intl, date);
}
|
So if isSecondaryCalendar option is enabled it will default to Nepali version. This could be reworked by other implementations in the future.
Currently we had to write separate DateFormatter for Nepal. New formatters would have to be written and added here to be accounted for by the code.
Additional thing worth mentioning:
isSecondaryCalendar is a variable representing current state of a date switcher - it tells openIMIS which calendar to show - gregorian or secondary (nepali in this case). We cannot come up with any other way than to write it down as a cookie and then read every time the button is pressed.
Other solutions seems to be to complicated to work, and other that was simple and obvious uses hooks. Hooks are used in react functional components and cannot be used in class components. And because this function is called across whole openIMIS, which is written mainly in class components this causes immediate failure of the frontend. If at some point openIMIS is reworked to rely on functional components only this could be reworked.
Product cycles (back-end)
...
Product cycles use dates not as a pickable single entry, but as integers representing day and month of a year:
...
Because of this, no changes are needed on the frontend to support different types of calendar (TBC - if it can support calendar with 13 months). This feature is locale agnostic.
On the backend side, we have a setting in the core module called secondary_calendar. This setting is a string only and tells us which calendar should be selected by product cycles method if any is needed.
Code for product cycles looks like this:
| Code Block |
|---|
if CoreConfig.secondary_calendar == 'Nepal':
import nepali_datetime
nepali_start = nepali_datetime.datetime.strptime("%s-%s" % (c, nepali_datetime.date.today().year), '%d-%m-%Y')
start = nepali_start.to_datetime_date()
else:
start = py_datetime.datetime.strptime("%s-%s" % (c, ref_date.year), '%d-%m-%Y') |
Which allows developer to add support for additional calendar in a easy way - just add another if statement that will convert date value stored as a pair of two strings to a date valid for a current year and convert it to values interpreted in gregorian date, so the rest of the business logic does not have to be changed.
Reports (back-end)
ReportBro does not seem to support it. I’ve opened an inssue on github - https://github.com/jobsta/reportbro-lib/issues/36 . We may have to add this support ourselves (reporbro is opensource).
...