On 16 April 2012 04:25, Steve Hathaway <shath...@e-z.net> wrote: > I am also acquainted with the Baha'i Calendar which is based > on the solar year. Year 1 falls in the year 1844 of the > Gregorian calendar. This calendar has 19 months of 19 days. > There are 4-5 intercalary days appended to the end of the > year. The new year (Naw Ruz) is not January 1. Leap years > are currently computed according to the Gregorian Algorithm.
Joda-Time is not supplied with the Baha'i calendar, but it should be possible to implement. > My understanding of the Gregorian Calendar differs slightly > from what the Joda-Time has in their documentation. > > Like the Julian Calendar, the Gregorian Calendar has no > year zero. The Year 1/BC immediately precedes the Year 1/AD. > And the Year 1/BC is the end of a 400-year cycle and is > therefore a leap year. Joda-Time has two separate year concepts. The year is the proleptic year used by astronomers. The year-of-era is the one you refer to here: dateTime.get(DateTimeFieldType.yearOfEra()); > The millisecond clock used for timing is also a concern. > Documentation mentions that the clock starts incrementing > millisecond counts at 1970-01-01T00:00Z. My recollection > indicates that the system clock of IBM 370/zSeries mainframes > is a millisecond clock (or microsecond clock) with a rollover vulnerability. > Does Joda-Time have a clock rollover vulnerabiltiy? Joda-Time uses 64 bit long for counting milliseconds. The rollover vulnerability is for systems using a 32 bit number. > I wish to have a calendar system that supports a longevity > of more than 100,000 years, both backwards and forwards on > a solar-based timeline. My preference is to have a timebase > that simulates the vernal (northward) equinox year in preference > to the sidereal year. This tends to promote the Gregorian > Calendar Algorithm of 400 year cycles to represent the > preferred timeline. > There is also a difference in what constitutes a solar year. > One is the measure of time between occurrences of the > vernal (northward) equinox. The other constitutes the > full orbit of the earth as measured by the stars. The > difference between the two computations of solar year is > the effective precession of the earth and the north pole. Joda-Time simply defines a millisecond based system and applies current ISO/Gregorian rules and 86400s day lengths to far future and far past. You could write your own chronology class to calculate differently, but Joda-Time might not be the right choice for that scenario. (ie. Joda-Time is not concerned with details of astronomy/equinox/stars etc - it is primarily concerned with dates and times for commerce. Use for astronomical length dates/times is totally by extrapolation) > It looks to me like Joda-Time is initially implemented to > render ISO years in the positive direction using the > Gregorian Calendar, starting at year 1. > > When reconciling calendars of antiquity on a time continuum, > I would like to see an interactive calendaring system that > can automatically reference specific dates and times > across multiple calendars. Given a Joda-Time date, it can be converted to a date in a different calendar system easily: dateTime.withChronology(CopticChronology.getInstance()) > Most calendars have a day starting in the middle of the night. > Some calendars of antiquity start the day at sunrise. - but these are rare. > Other calendars of antiquity start the day at dusk - but these are rare. Joda-Time has no support for days that do not start at midnight. However, a chronology could be coded that did have such support > Microsoft has also coded for some lunar calendars, but the code is not > open-source. > > Microsoft in their MSDN library has an example of adding > 5 to year, month, day, hour, minute, and second. > I have not yet proven the correctness of their algorithms or their result. I don't know the MSDN classes, but Joda-Time supports addition. Hope this helps Stephen ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
