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
