Second calendar settings
- Wojciech Zgliniecki (Deactivated)
Introduction
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.
General information and settings
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.
Enabled with setting:
- `calendarSwitch`: enable calendar switcher toggle on the navbar of the webpage. Default false.
Pickers (front-end)
Currently used component for secondary calendar is react-multi-date-picker. It was picked by us to support for many calendars (Indian, Persian, Gregorian, Arabic) and a lot of customizable options as well as ongoing support by developers.
If you need support for calendar not defined here, you can create one yourself (provided it is 12 months long, other calendars are not yet supported by this picker) using this guide. Additionally nepali calendar files can be used as a reference (files in calendars directory).
To calculate epoch value, the following code was used (although I had to add around 500 manually):
import { DateObject } from "react-multi-date-picker";
const julianDay = new DateObject().toJulianDay();
const days = new DateObject().add(56, "years").add(8, "months").add(17, "days").toDays();
console.log(new DateObject().add(56, "years").add(8, "months").add(17, "days").toDate());
const epoch = julianDay - days
After adding those files and adding them to relevant dictionaries in the code, you need to specify following settings for your calendar to be used:
- `secondCalendarType`: type of secondary calendar picker (if enabled), default "nepali"
- `secondCalendarLocale`: locale for secondary calendar picker (if enabled), default "nepali_en"Display (front-end)
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.
Current implementation will need refactoring if it were to use any other calendar than Nepali. It looks like this:
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:
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).
Did you encounter a problem or do you have a suggestion?
Please contact our Service Desk
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/