You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Steve Hathaway <sh...@e-z.net> on 2012/04/14 07:01:40 UTC
Gregorian Calendar Date-Time Functions (Xalan EXSLT)
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
<sh...@apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Gregorian Calendar Date-Time Functions (Xalan EXSLT)
Posted by Gary Gregory <ga...@gmail.com>.
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 <sh...@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<sh...@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
>>> <sh...@apache.org>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
>>> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Gregorian Calendar Date-Time Functions (Xalan EXSLT)
Posted by Steve Hathaway <sh...@e-z.net>.
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<sh...@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
>> <sh...@apache.org>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Gregorian Calendar Date-Time Functions (Xalan EXSLT)
Posted by Gary Gregory <ga...@gmail.com>.
Joda-Time might be helpful here.
Gary
On Apr 14, 2012, at 1:02, Steve Hathaway <sh...@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
> <sh...@apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org