dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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
>>>
>>>
>>
>