dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #22004
Re: Non-gregorian calendar systems
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@xxxxxxxxx>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 PURKAYASTHA
>
> My Tech Blog: http://sunnytalkstech.blogspot.com
> You Live by CHOICE, Not by CHANCE
>
>
> On 12 April 2013 12:56, Jason Pickering <jason.p.pickering@xxxxxxxxx>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?
>>
>> Best regards,
>> Jason
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
Follow ups
References