yes that is what I understood.
On 13 April 2013 13:38, Saptarshi Purkayastha <sun...@gmail.com> 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 <bobjolli...@gmail.com> wrote: > >> On 13 April 2013 13:26, Saptarshi Purkayastha <sun...@gmail.com> 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.picker...@gmail.com>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 < >>>> sun...@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 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.picker...@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 >>>>>> <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@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> >
_______________________________________________ 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
