To the Joda-Time Development Team:
I am looking at Joda-Time for guidance on deploying multiple calendars and a system that allows functional cross-reference of events happening at a specific dates and times in history. The Joda-Time looks promising, but I do have some concerns regarding the underlying Chronology class and how calendars are reconciled. 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. 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. 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? 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. 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. 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. 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. Most of my calendaring issues are to be implemented in C/C++ libraries. I am hoping to see if Joda-Time libraries can be functionally ported to or implemented on the C/C++ platforms. I want the libraries to be long-lived without clock rollover issues. Sincerely, Steven J. Hathaway Apache Xalan Documentation Project ==== PREVIOUS COMMUNICATIONS ==== ref: mail list: ([hidden email]) Hi Steven, Do you mind posting your comments on the JD mailing list. I am curious as to what the feed back will be. http://joda-time.sourceforge.net/mail-lists.html Thank you, Gary On Apr 15, 2012, at 12:55, Steve Hathaway [hidden email] wrote: On 4/14/2012 4:57 AM, Gary Gregory wrote:Joda-Time might be helpful here. GaryJoda-Time issues: 1. The Chronology class is based on the microsecond timekeeping clock used for the JDK date-time methods. Like the IBM 370/zSeries, it has rollover issues. The Joda-Time timekeeping clock at count=(0), zero, references the timestamp 1970-01-01T00:00Z. 2. The Joda-Time Gregorian Calendar implements a year zero. The historical specification of the Gregorian Calendar, like the Julian Calendar has no year zero. The first year of the calendar is (1). The previous year (before epoc) is (-1) which is also a leap year. 3. I am looking for a solar calendar chronology to which calendars of antiquity can be authoritatively referenced. New calendars should also be capable of reference to the chronology. Each calendar implementation supplies its own chronology rules that can be mapped to a long-term solar chronology. The underlying solar chronology should be backward and forward capapable of a hundred-thousand years. FYI: The Baha'i Calendar has a solar basis. Year 1 of the Baha'i calendar is the year 1844 of the Gregorian Calendar. There are 19 months of 19 days, and 4 or 5 intercalary days appended to the end of the calendar year to accommodate Leap Year. The Leap Year computation is rendered according the the Gregorian Calendar algorithm. The Baha'i new year (Naw Ruz) is not January 1. 4. It should be easy to map lunar cycle chronology to the solar cycle chronology. The chronologies should be able to be synchronized by specific algorithms. 5. The Joda-Time chronology is designed to handle the expressions of modern calendars, but significant problems exist when trying to reconcile calendars of antiquity. Joda-Time also has chronology integrity issues based on numerical rollover issues associated with the underlying microsecond timekeeping clock. 6. I am proposing that the solar chronology be based on the 400-year Gregorian algorithm. This has now become the defacto standard algorithm of solar chronology to which modern calendars, and calendars of antiquity are being referenced. 7. Calendar implementations should be large cycle based in a manner to ease computation, and to avoid long-term implementation issues. The Joda-Time implementation falls short on some of these issues. Can the Joda-Time project be refactored to handle these issues, or should another library be implemented. The Joda-Time implementation is Java based. I have systems that are C/C++ based. The Joda-Time project documents a Java implementation to address many of the needs of timekeeping and calendar representations. The underlying Joda-Time timekeeping clock infrastructure now appears to be the Achilles heel for implementation longevity and inter-calendar correlation correctness. To confirm or disprove my suspicions, a detailed analysis of the Java-Time source code is required. Steven J. HathwayOn Apr 14, 2012, at 1:02, Steve Hathaway[hidden email] wrote:Samuel, There are several ASF projects that could use a robust implementation of Gregorian Calendar DateTime that accommodates both (AD) Normal and (BC) Negative Years. Such an algorithm is essential for mapping calendars of antiquity to a robust solar time standard algorithm such as exists in the Gregorian Calendar algorithm. If we can come up with an algorithm that implements the Gregorian Calendar date-time functions in C, C++, and Java -- I believe that the resulting code would be gladly accepted in many of the other ASF projects. Even the organizations that support the web standards consortium, will probably be interested in a solid Gregorian date-time library (http://www.w3.org). The support of negative Gregorian Calendar Years is beyond the initial scope of the EXSLT project. If we can get a proof of concept and documentation for (BC) date-time computations, I can assist in getting the results published. If the EXSLT project only implements (AD) Gregorian dates of positive years, that would be a big improvement over what we have! POS-CYCLE (AD) NEG-CYCLE (BC) 0001 not-leap -0400 not-leap Cycle Start Day = 0 0002 not-leap -0399 not-leap 0003 not-leap -0398 not-leap 0004 leap -0397 leap 0008 leap -0393 leap 0012 leap -0389 leap 0016 leap -0385 leap 0020 leap -0381 leap 0100 not-leap -0301 not leap 0200 not-leap -0201 not leap 0300 not-leap -0101 not leap 0400 leap -0001 leap Cycle End Day = 146096 Note: Within the NEG-CYCLE Gregorian, the months and days have a monotonic positive sequence whereas the years have a monotonic negative sequence. We cannot just perform a negative inverse of everything. We just create a transposed Gregorian 400 year cycle and iterate the days and months in a positive manner and declare only the years as a negative inverse. Note also that leap-year analysis is done according to the transposed Gregorian Cycle instead of the numeric year value. An analysis of negative years (omitting Year = zero), it is possible to create a useful algorithm for computing leap years and leap centuries where Year is in the (BC) range. Converting Negative or (BC) Years to a useful numeric for Positive Gregorian Cycle algorithms, just add the appropriate 401, 801, 1201, 1601, 2001 to the negative year, and the year result is transformed into a positive number that is compatible with the simple leap-year computation For example: Year -0397, add 0401, result = 4 which is a leap year. Another example: Year -0201, add 0401, result = 200 which is not a leap century. Calendars of antiquity are being positioned on the extrapolated Gregorian calendar algorithm according to the above rules. Maintaining the positive daily and monthly numbering also allows positioning of various religious, secular, and public festivals in their appropriate season when mapped to the other calendars. The Unix "cal" calendar program does not allow negative years for (BC) computation. ======================================================== - - - -0800 = cycle start (day = 0) -0797 a leap year -0701 not a leap year -0601 not a leap year -0501 not a leap year -0401 = cycle end (day = 146096) a leap year - - - -0400 = cycle start (day = 0) not a leap year -0397 a leap year -0301 not a leap year -0201 not a leap year -0101 not a leap year -0001 = cycle end (day = 146096) a leap year ========<epoc break>======= 0001 = cycle start (day = 0) not a leap year 0004 a leap year 0100 not a leap year 0200 not a leap year 0300 not a leap year 0400 = cycle end (day = 146096) a leap year - - - 0401 = cycle start (day = 0) 0404 a leap year 0500 not a leap year 0600 not a leap year 0700 not a leap year 0800 = cycle end (day = 146096) a leap year - - - ======================================== Trivia: What year did King Harod die? Answer: Year 4 (BC) Gregorian Calendar. Now, how did Rome determine that year 1 of the Gregorian Calendar was to be the year of the birth of Jesus, the Christ? (I have no answer.) Sincerely, Steven J. Hathaway Xalan Documentation Project [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]--------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]--------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Joda-interest mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/joda-interest |
On 16 April 2012 04:25, Steve Hathaway <[hidden email]> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/joda-interest |
Free forum by Nabble | Edit this page |