Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems. This issue has come up in a couple of different places which I know of, namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri calendar). Currently, the system only supports a Gregorian calendar system, but I am trying to think of ways how we can support different ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian calendar. I dug out some code here which will convert between Gregorian dates and BS dates (but not the other way around). The approach is to use a look-up table, because of the fact that it seems to be difficult (if not impossible) to calculate the conversion algorithmically.
This leads me to my question. Would it be possible that we consider adding a “Calendar system” to the application. The default would be “Gregorian”, which is currently the case. The Second alternative might be “Bikram Sambat”. This would require someone to prepopulate the system with periods (BS months, quarters and years) which would be calculated through some other means (common Lisp code here which may be able to do this). These would be in Gregorian periods, but instead of the system calculating future periods, they would have to be pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the use of the JavaScript Gregorian calendar throughout the system. For data entry of aggregate data, it would not to be too problematic. But for the tracker module (and other places in the system), a Gregorian Javascript widget is used, and it would seem to be potentially difficult to replace this.
Could the developers comment on feasibility and possible level of effort?
When you say the system currently only support Gregorian calendar, I wonder if that’s a fact of JavaScript widgets
But while I was writing this email, a quick search in the code base shows that we’ve instantiated Gregorian calendar at many places instead of using the more localized Calendar.getInstance(). The first task would be move to using this
Secondly, is conversion between Gregorian dates and some other calendar really required. If data is exchanged between different systems with different calendars, this is important. But if we are storing a timestamp in database, it should be fine to store it in the locale calendar. So I am not too keen, unless really required to use the maps that allow co-relating dates between calendar systems.
Thirdly, there are quite a few (and fairly easy to write new JavaScript calendars) to suite different locales. The care that we need to take is being able to retrieve the correct calendar based on the set locale. A simple BS calendar JS - http://sajanmaharjan.com.np/my-works/nepali-datepicker-ui/
Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems. This issue has come up in a couple of different places which I know of, namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri calendar). Currently, the system only supports a Gregorian calendar system, but I am trying to think of ways how we can support different ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian calendar. I dug out some code here which will convert between Gregorian dates and BS dates (but not the other way around). The approach is to use a look-up table, because of the fact that it seems to be difficult (if not impossible) to calculate the conversion algorithmically.
This leads me to my question. Would it be possible that we consider adding a “Calendar system” to the application. The default would be “Gregorian”, which is currently the case. The Second alternative might be “Bikram Sambat”. This would require someone to prepopulate the system with periods (BS months, quarters and years) which would be calculated through some other means (common Lisp code here which may be able to do this). These would be in Gregorian periods, but instead of the system calculating future periods, they would have to be pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the use of the JavaScript Gregorian calendar throughout the system. For data entry of aggregate data, it would not to be too problematic. But for the tracker module (and other places in the system), a Gregorian Javascript widget is used, and it would seem to be potentially difficult to replace this.
Could the developers comment on feasibility and possible level of effort?
Hi Saptarshi,
Yes, I cannot speculate really why DHIS2 only supports the Gregorian calendar, but this issue I think has been discussed a few times on the list before (perhaps for other countries).
I feel the best approach would be to store all of the data with Gregorian dates, but what is shown through the web UI would be the calendar system of the particular instance. I am not even sure if databases like Postgres and MySQL (much less the operating system itself) would support non Gregorian calendar systems.
As for data exchange, I see no immediate need for this, but if data is stored in Gregorian format ( I suppose the de facto international standard), then perhaps data exchange would be somewhat easier, but this is just speculation of course.
Thanks for the link to the BS date picker. Does not seem to difficult to solve at least this problem.The bigger issue as I see it would be data entry through mobiles. At least the J2ME app uses the system calendar, and do not think that non-Gregorian systems are even supported on any phone?
Best regards,
Jason
···
On Fri, Apr 12, 2013 at 5:16 PM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Hi Jason,
When you say the system currently only support Gregorian calendar, I wonder if that’s a fact of JavaScript widgets
But while I was writing this email, a quick search in the code base shows that we’ve instantiated Gregorian calendar at many places instead of using the more localized Calendar.getInstance(). The first task would be move to using this
Secondly, is conversion between Gregorian dates and some other calendar really required. If data is exchanged between different systems with different calendars, this is important. But if we are storing a timestamp in database, it should be fine to store it in the locale calendar. So I am not too keen, unless really required to use the maps that allow co-relating dates between calendar systems.
Thirdly, there are quite a few (and fairly easy to write new JavaScript calendars) to suite different locales. The care that we need to take is being able to retrieve the correct calendar based on the set locale. A simple BS calendar JS - http://sajanmaharjan.com.np/my-works/nepali-datepicker-ui/
Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems. This issue has come up in a couple of different places which I know of, namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri calendar). Currently, the system only supports a Gregorian calendar system, but I am trying to think of ways how we can support different ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian calendar. I dug out some code here which will convert between Gregorian dates and BS dates (but not the other way around). The approach is to use a look-up table, because of the fact that it seems to be difficult (if not impossible) to calculate the conversion algorithmically.
This leads me to my question. Would it be possible that we consider adding a “Calendar system” to the application. The default would be “Gregorian”, which is currently the case. The Second alternative might be “Bikram Sambat”. This would require someone to prepopulate the system with periods (BS months, quarters and years) which would be calculated through some other means (common Lisp code here which may be able to do this). These would be in Gregorian periods, but instead of the system calculating future periods, they would have to be pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the use of the JavaScript Gregorian calendar throughout the system. For data entry of aggregate data, it would not to be too problematic. But for the tracker module (and other places in the system), a Gregorian Javascript widget is used, and it would seem to be potentially difficult to replace this.
Could the developers comment on feasibility and possible level of effort?
I think we should be Calendar agnostic in code and like most i18n capable systems, not expect the timestamp in the database to be Calendar-specific
Postgres for instance uses Julian calendar internally. But still supports many different systems, much more than standard SQL asks for.
Java similar uses long values, instead of Calendar-specific representations.
My point is, Java, Postgres (and MySQL) are well designed to work by being calendar-agnostic.
Also, Joda-time provides nice Chronology classes for different calendars, which we can use for localized storing, retrieving or converting
For the JavaME app in one of the releases, we did have a custom calendar component.
Having it display BS, Ethiopian or anything else, should be fairly easy. But yes, very few low-end Java phones are locale specific.
···
On Fri, Apr 12, 2013 at 5:16 PM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Hi Jason,
When you say the system currently only support Gregorian calendar, I wonder if that’s a fact of JavaScript widgets
But while I was writing this email, a quick search in the code base shows that we’ve instantiated Gregorian calendar at many places instead of using the more localized Calendar.getInstance(). The first task would be move to using this
Secondly, is conversion between Gregorian dates and some other calendar really required. If data is exchanged between different systems with different calendars, this is important. But if we are storing a timestamp in database, it should be fine to store it in the locale calendar. So I am not too keen, unless really required to use the maps that allow co-relating dates between calendar systems.
Thirdly, there are quite a few (and fairly easy to write new JavaScript calendars) to suite different locales. The care that we need to take is being able to retrieve the correct calendar based on the set locale. A simple BS calendar JS - http://sajanmaharjan.com.np/my-works/nepali-datepicker-ui/
Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems. This issue has come up in a couple of different places which I know of, namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri calendar). Currently, the system only supports a Gregorian calendar system, but I am trying to think of ways how we can support different ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian calendar. I dug out some code here which will convert between Gregorian dates and BS dates (but not the other way around). The approach is to use a look-up table, because of the fact that it seems to be difficult (if not impossible) to calculate the conversion algorithmically.
This leads me to my question. Would it be possible that we consider adding a “Calendar system” to the application. The default would be “Gregorian”, which is currently the case. The Second alternative might be “Bikram Sambat”. This would require someone to prepopulate the system with periods (BS months, quarters and years) which would be calculated through some other means (common Lisp code here which may be able to do this). These would be in Gregorian periods, but instead of the system calculating future periods, they would have to be pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the use of the JavaScript Gregorian calendar throughout the system. For data entry of aggregate data, it would not to be too problematic. But for the tracker module (and other places in the system), a Gregorian Javascript widget is used, and it would seem to be potentially difficult to replace this.
Could the developers comment on feasibility and possible level of effort?
I think we should be Calendar agnostic in code and like most i18n capable
systems, not expect the timestamp in the database to be Calendar-specific
Postgres for instance uses Julian calendar internally. But still supports
many different systems, much more than standard SQL asks for.
Java similar uses long values, instead of Calendar-specific
representations.
Am I right in thinking joda-time is now integrated into the java.time
package of java 8?
···
On 13 April 2013 13:26, Saptarshi Purkayastha <sunbiz@gmail.com> wrote:
For the JavaME app in one of the releases, we did have a custom calendar
component.
Having it display BS, Ethiopian or anything else, should be fairly easy.
But yes, very few low-end Java phones are locale specific.
On 13 April 2013 10:36, Jason Pickering <jason.p.pickering@gmail.com>wrote:
Hi Saptarshi,
Yes, I cannot speculate really why DHIS2 only supports the Gregorian
calendar, but this issue I think has been discussed a few times on the list
before (perhaps for other countries).
I feel the best approach would be to store all of the data with Gregorian
dates, but what is shown through the web UI would be the calendar system of
the particular instance. I am not even sure if databases like Postgres and
MySQL (much less the operating system itself) would support non Gregorian
calendar systems.
As for data exchange, I see no immediate need for this, but if data is
stored in Gregorian format ( I suppose the de facto international
standard), then perhaps data exchange would be somewhat easier, but this is
just speculation of course.
Thanks for the link to the BS date picker. Does not seem to difficult to
solve at least this problem.The bigger issue as I see it would be data
entry through mobiles. At least the J2ME app uses the system calendar, and
do not think that non-Gregorian systems are even supported on any phone?
Best regards,
Jason
On Fri, Apr 12, 2013 at 5:16 PM, Saptarshi Purkayastha <sunbiz@gmail.com>wrote:
Hi Jason,
When you say the system currently only support Gregorian calendar, I
wonder if that's a fact of JavaScript widgets
But while I was writing this email, a quick search in the code base
shows that we've instantiated Gregorian calendar at many places instead of
using the more localized Calendar.getInstance(). The first task would be
move to using this
Secondly, is conversion between Gregorian dates and some other calendar
really required. If data is exchanged between different systems with
different calendars, this is important. But if we are storing a timestamp
in database, it should be fine to store it in the locale calendar. So I am
not too keen, unless really required to use the maps that allow co-relating
dates between calendar systems.
Thirdly, there are quite a few (and fairly easy to write new JavaScript
calendars) to suite different locales. The care that we need to take is
being able to retrieve the correct calendar based on the set locale. A
simple BS calendar JS - http://sajanmaharjan.com.np/my-works/nepali-datepicker-ui/
On 12 April 2013 12:56, Jason Pickering <jason.p.pickering@gmail.com>wrote:
Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems.
This issue has come up in a couple of different places which I know of,
namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri
calendar). Currently, the system only supports a Gregorian calendar system,
but I am trying to think of ways how we can support different
ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian
calendar. I dug out some code here
<https://github.com/bahadurbaniya/Date-Converter-Bikram-Sambat-to-English-Date> which
will convert between Gregorian dates and BS dates (but not the other way
around). The approach is to use a look-up table, because of the fact that
it seems to be difficult (if not impossible) to calculate the
conversion algorithmically.
This leads me to my question. Would it be possible that we consider
adding a "Calendar system" to the application. The default would be
"Gregorian", which is currently the case. The Second alternative might be
"Bikram Sambat". This would require someone to prepopulate the system with
periods (BS months, quarters and years) which would be calculated through
some other means (common Lisp code here<http://emr.cs.uiuc.edu/~reingold/calendar.l> which
may be able to do this). These would be in Gregorian periods, but instead
of the system calculating future periods, they would have to be
pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the
use of the JavaScript Gregorian calendar throughout the system. For data
entry of aggregate data, it would not to be too problematic. But for the
tracker module (and other places in the system), a Gregorian Javascript
widget is used, and it would seem to be potentially difficult to replace
this.
Could the developers comment on feasibility and possible level of
effort?
Not joda-time exactly… but JSR310, which learnt most things from joda-time
This has been in the Java8 release since last 6 months or so
···
I think we should be Calendar agnostic in code and like most i18n capable systems, not expect the timestamp in the database to be Calendar-specific
Postgres for instance uses Julian calendar internally. But still supports many different systems, much more than standard SQL asks for.
Java similar uses long values, instead of Calendar-specific representations.
My point is, Java, Postgres (and MySQL) are well designed to work by being calendar-agnostic.
Also, Joda-time provides nice Chronology classes for different calendars, which we can use for localized storing, retrieving or converting
Am I right in thinking joda-time is now integrated into the java.time package of java 8?
For the JavaME app in one of the releases, we did have a custom calendar component.
Having it display BS, Ethiopian or anything else, should be fairly easy. But yes, very few low-end Java phones are locale specific.
Hi Saptarshi,
Yes, I cannot speculate really why DHIS2 only supports the Gregorian calendar, but this issue I think has been discussed a few times on the list before (perhaps for other countries).
I feel the best approach would be to store all of the data with Gregorian dates, but what is shown through the web UI would be the calendar system of the particular instance. I am not even sure if databases like Postgres and MySQL (much less the operating system itself) would support non Gregorian calendar systems.
As for data exchange, I see no immediate need for this, but if data is stored in Gregorian format ( I suppose the de facto international standard), then perhaps data exchange would be somewhat easier, but this is just speculation of course.
Thanks for the link to the BS date picker. Does not seem to difficult to solve at least this problem.The bigger issue as I see it would be data entry through mobiles. At least the J2ME app uses the system calendar, and do not think that non-Gregorian systems are even supported on any phone?
On Fri, Apr 12, 2013 at 5:16 PM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Hi Jason,
When you say the system currently only support Gregorian calendar, I wonder if that’s a fact of JavaScript widgets
But while I was writing this email, a quick search in the code base shows that we’ve instantiated Gregorian calendar at many places instead of using the more localized Calendar.getInstance(). The first task would be move to using this
Secondly, is conversion between Gregorian dates and some other calendar really required. If data is exchanged between different systems with different calendars, this is important. But if we are storing a timestamp in database, it should be fine to store it in the locale calendar. So I am not too keen, unless really required to use the maps that allow co-relating dates between calendar systems.
Thirdly, there are quite a few (and fairly easy to write new JavaScript calendars) to suite different locales. The care that we need to take is being able to retrieve the correct calendar based on the set locale. A simple BS calendar JS - http://sajanmaharjan.com.np/my-works/nepali-datepicker-ui/
Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems. This issue has come up in a couple of different places which I know of, namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri calendar). Currently, the system only supports a Gregorian calendar system, but I am trying to think of ways how we can support different ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian calendar. I dug out some code here which will convert between Gregorian dates and BS dates (but not the other way around). The approach is to use a look-up table, because of the fact that it seems to be difficult (if not impossible) to calculate the conversion algorithmically.
This leads me to my question. Would it be possible that we consider adding a “Calendar system” to the application. The default would be “Gregorian”, which is currently the case. The Second alternative might be “Bikram Sambat”. This would require someone to prepopulate the system with periods (BS months, quarters and years) which would be calculated through some other means (common Lisp code here which may be able to do this). These would be in Gregorian periods, but instead of the system calculating future periods, they would have to be pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the use of the JavaScript Gregorian calendar throughout the system. For data entry of aggregate data, it would not to be too problematic. But for the tracker module (and other places in the system), a Gregorian Javascript widget is used, and it would seem to be potentially difficult to replace this.
Could the developers comment on feasibility and possible level of effort?
On 13 April 2013 13:26, Saptarshi Purkayastha sunbiz@gmail.com wrote:
I think we should be Calendar agnostic in code and like most i18n capable systems, not expect the timestamp in the database to be Calendar-specific
Postgres for instance uses Julian calendar internally. But still supports many different systems, much more than standard SQL asks for.
Java similar uses long values, instead of Calendar-specific representations.
My point is, Java, Postgres (and MySQL) are well designed to work by being calendar-agnostic.
Also, Joda-time provides nice Chronology classes for different calendars, which we can use for localized storing, retrieving or converting
Am I right in thinking joda-time is now integrated into the java.time package of java 8?
For the JavaME app in one of the releases, we did have a custom calendar component.
Having it display BS, Ethiopian or anything else, should be fairly easy. But yes, very few low-end Java phones are locale specific.
Hi Saptarshi,
Yes, I cannot speculate really why DHIS2 only supports the Gregorian calendar, but this issue I think has been discussed a few times on the list before (perhaps for other countries).
I feel the best approach would be to store all of the data with Gregorian dates, but what is shown through the web UI would be the calendar system of the particular instance. I am not even sure if databases like Postgres and MySQL (much less the operating system itself) would support non Gregorian calendar systems.
As for data exchange, I see no immediate need for this, but if data is stored in Gregorian format ( I suppose the de facto international standard), then perhaps data exchange would be somewhat easier, but this is just speculation of course.
Thanks for the link to the BS date picker. Does not seem to difficult to solve at least this problem.The bigger issue as I see it would be data entry through mobiles. At least the J2ME app uses the system calendar, and do not think that non-Gregorian systems are even supported on any phone?
On Fri, Apr 12, 2013 at 5:16 PM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Hi Jason,
When you say the system currently only support Gregorian calendar, I wonder if that’s a fact of JavaScript widgets
But while I was writing this email, a quick search in the code base shows that we’ve instantiated Gregorian calendar at many places instead of using the more localized Calendar.getInstance(). The first task would be move to using this
Secondly, is conversion between Gregorian dates and some other calendar really required. If data is exchanged between different systems with different calendars, this is important. But if we are storing a timestamp in database, it should be fine to store it in the locale calendar. So I am not too keen, unless really required to use the maps that allow co-relating dates between calendar systems.
Thirdly, there are quite a few (and fairly easy to write new JavaScript calendars) to suite different locales. The care that we need to take is being able to retrieve the correct calendar based on the set locale. A simple BS calendar JS - http://sajanmaharjan.com.np/my-works/nepali-datepicker-ui/
Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems. This issue has come up in a couple of different places which I know of, namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri calendar). Currently, the system only supports a Gregorian calendar system, but I am trying to think of ways how we can support different ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian calendar. I dug out some code here which will convert between Gregorian dates and BS dates (but not the other way around). The approach is to use a look-up table, because of the fact that it seems to be difficult (if not impossible) to calculate the conversion algorithmically.
This leads me to my question. Would it be possible that we consider adding a “Calendar system” to the application. The default would be “Gregorian”, which is currently the case. The Second alternative might be “Bikram Sambat”. This would require someone to prepopulate the system with periods (BS months, quarters and years) which would be calculated through some other means (common Lisp code here which may be able to do this). These would be in Gregorian periods, but instead of the system calculating future periods, they would have to be pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the use of the JavaScript Gregorian calendar throughout the system. For data entry of aggregate data, it would not to be too problematic. But for the tracker module (and other places in the system), a Gregorian Javascript widget is used, and it would seem to be potentially difficult to replace this.
Could the developers comment on feasibility and possible level of effort?
to me this sounds doable but tricky. Will require that we change the PeriodType classes/implementation to support lookup tables. We will need two-way conversion since Postgres does not support storage of these Hirji dates (without extensions at least). And it will require that we factor this into data mart and analytics tables and queries.
So yes it would be great to have but cannot promise it anytime soon… We are of course open for contributions if someone wants to take on this task.
On 13 April 2013 13:26, Saptarshi Purkayastha sunbiz@gmail.com wrote:
I think we should be Calendar agnostic in code and like most i18n capable systems, not expect the timestamp in the database to be Calendar-specific
Postgres for instance uses Julian calendar internally. But still supports many different systems, much more than standard SQL asks for.
Java similar uses long values, instead of Calendar-specific representations.
My point is, Java, Postgres (and MySQL) are well designed to work by being calendar-agnostic.
Also, Joda-time provides nice Chronology classes for different calendars, which we can use for localized storing, retrieving or converting
Am I right in thinking joda-time is now integrated into the java.time package of java 8?
For the JavaME app in one of the releases, we did have a custom calendar component.
Having it display BS, Ethiopian or anything else, should be fairly easy. But yes, very few low-end Java phones are locale specific.
Hi Saptarshi,
Yes, I cannot speculate really why DHIS2 only supports the Gregorian calendar, but this issue I think has been discussed a few times on the list before (perhaps for other countries).
I feel the best approach would be to store all of the data with Gregorian dates, but what is shown through the web UI would be the calendar system of the particular instance. I am not even sure if databases like Postgres and MySQL (much less the operating system itself) would support non Gregorian calendar systems.
As for data exchange, I see no immediate need for this, but if data is stored in Gregorian format ( I suppose the de facto international standard), then perhaps data exchange would be somewhat easier, but this is just speculation of course.
Thanks for the link to the BS date picker. Does not seem to difficult to solve at least this problem.The bigger issue as I see it would be data entry through mobiles. At least the J2ME app uses the system calendar, and do not think that non-Gregorian systems are even supported on any phone?
On Fri, Apr 12, 2013 at 5:16 PM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Hi Jason,
When you say the system currently only support Gregorian calendar, I wonder if that’s a fact of JavaScript widgets
But while I was writing this email, a quick search in the code base shows that we’ve instantiated Gregorian calendar at many places instead of using the more localized Calendar.getInstance(). The first task would be move to using this
Secondly, is conversion between Gregorian dates and some other calendar really required. If data is exchanged between different systems with different calendars, this is important. But if we are storing a timestamp in database, it should be fine to store it in the locale calendar. So I am not too keen, unless really required to use the maps that allow co-relating dates between calendar systems.
Thirdly, there are quite a few (and fairly easy to write new JavaScript calendars) to suite different locales. The care that we need to take is being able to retrieve the correct calendar based on the set locale. A simple BS calendar JS - http://sajanmaharjan.com.np/my-works/nepali-datepicker-ui/
Hi Devs,
I have a question regarding non-Gregorian (Western) calendar systems. This issue has come up in a couple of different places which I know of, namely Ethiopia (Ethiopian calendar) and Afghanistan (Solar Hijri calendar). Currently, the system only supports a Gregorian calendar system, but I am trying to think of ways how we can support different ones, specifically the Bikram Sambat (BS) calendar system used in Nepal.
There appears to be no easy way to convert between a Gregorian calendar. I dug out some code here which will convert between Gregorian dates and BS dates (but not the other way around). The approach is to use a look-up table, because of the fact that it seems to be difficult (if not impossible) to calculate the conversion algorithmically.
This leads me to my question. Would it be possible that we consider adding a “Calendar system” to the application. The default would be “Gregorian”, which is currently the case. The Second alternative might be “Bikram Sambat”. This would require someone to prepopulate the system with periods (BS months, quarters and years) which would be calculated through some other means (common Lisp code here which may be able to do this). These would be in Gregorian periods, but instead of the system calculating future periods, they would have to be pre-calculated and entered/imported into the system somehow.
The second part of this (which I think may be more difficult) is the use of the JavaScript Gregorian calendar throughout the system. For data entry of aggregate data, it would not to be too problematic. But for the tracker module (and other places in the system), a Gregorian Javascript widget is used, and it would seem to be potentially difficult to replace this.
Could the developers comment on feasibility and possible level of effort?