dhis2-devs team mailing list archive

[Saptarshi Purkayastha <sunbiz@xxxxxxxxx>]

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<http://joda-time.sourceforge.net/apidocs/org/joda/time/chrono/package-summary.html>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.

---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE


On 13 April 2013 10:36, Jason Pickering <jason.p.pickering@xxxxxxxxx> 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@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
>>>
>>>
>>
>