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 <shath...@e-z.net> wrote: > On 4/14/2012 4:57 AM, Gary Gregory wrote: >> Joda-Time might be helpful here. >> >> Gary > Joda-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. Hathway > >> On Apr 14, 2012, at 1:02, Steve Hathaway<shath...@e-z.net> 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 >>> <shatha...@apache.org> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org >>> For additional commands, e-mail: xalan-dev-h...@xml.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org >> For additional commands, e-mail: xalan-dev-h...@xml.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org > For additional commands, e-mail: xalan-dev-h...@xml.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org For additional commands, e-mail: xalan-dev-h...@xml.apache.org
