Joda-Time Implementation Issues - Calendars of Antiquity

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Joda-Time Implementation Issues - Calendars of Antiquity

Steve Hathaway
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.

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[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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Joda-Time Implementation Issues - Calendars of Antiquity

jodastephen
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
Loading...