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/
Regards,
Saptarshi PURKAYASTHAMy Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
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 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?
Best regards,
Jason
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp