dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Hi,

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.

regards,

Lars



On Sat, Apr 13, 2013 at 2:50 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> yes that is what I understood.
>
>
> On 13 April 2013 13:38, Saptarshi Purkayastha <sunbiz@xxxxxxxxx> wrote:
>
>> 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
>>
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>> You Live by CHOICE, Not by CHANCE
>>
>>
>> On 13 April 2013 13:33, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>>> On 13 April 2013 13:26, Saptarshi Purkayastha <sunbiz@xxxxxxxxx> 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<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
>>>>
>>>
>>> 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.
>>>>
>>>>
>>>> ---
>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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
>
>