One major struggle for any calendar reform (or revival) proposal to get actually implemented is software support. A first but major step around that problem would be ICU, the International Components for Unicode. This library, written both in Java and C, is used by many major vendors.
> The Calendar class is designed to support additional calendar systems in the future.
If someone can get a calendar into ICU, some kind of support will follow over time, but I'm not sure whether that is realistic at all, especially for recent reform proposals.
It should be possible for calendars like the French Republican or perhaps even the International Fixed Calendar. If abstracted enough, existing CLDR variables (i.e. Days in week (min), First day of week, First day of weekend, Last day of weekend) can be used to model closely related systems that would fit local traditions automatically.
More background info, while ICU is for implementations of algorithms, CLDR is for localized variables and names:
Thanks to Christoph Päper for informing us about the ICU. (I don't see
anywhere what "ICU" is an abbreviation for.) The goals of this (quite
ambitious) project are certainly to be commended.
I looked through http://userguide.icu-project.org/datetime/calendar and
noted what seems to me something missing. Under "Gregorian Calendar"
"Historically, most western countries used the Julian calendar until
the 16th to 20th century, depending on the country. They then switched
to the Gregorian calendar. The GregorianCalendar class mirrors this
behavior by defining a cut-over date. Before this date, the Julian
calendar algorithms are used. After it, the Gregorian calendar
algorithms are used. By default, the cut-over date is set to October 4,
1582 C.E ..."
I am not a great fan of this fusion of the Julian and the Gregorian
Calendars into one calendar (and actually it is not one calendar
because each different cut-over date specifies a different calendar).
I prefer to think calendrically in terms of two calendars: the
Proleptic Gregorian Calendar (with dates projected backward beyond
1582-10-15) and the Proleptic Julian Calendar (with dates projected
backward beyond 46 BCE). For example, we can say that Julian Day
Number 0 is -4712-01-01 in the Proleptic Julian Calendar or is
-4713-11-24 in the Proleptic Gregorian Calendar. Similarly we can
specify the GMT correlation with the Maya Calendar long count date
0.0.0.0.0 4 Ahau 8 Cumku by means of a date in either proleptic
If the Julian and Gregorian Calendars are combined, as the ICU
Gregorian Calendar class does, then whenever this class is used in
computation an additional parameter must be stated, namely, the
cut-over date, which makes this 'fusion' calendar valid only for those
countries which made the change at that date.
Dates of astronomical events such as eclipses, occurring prior to the
16th C. are often given as (Proleptic) Julian Calendar dates, but may
also be given as (Proleptic) Gregorian Calendar dates. This is not a
problem as long as one is clear which (proleptic) calendar is being
used. A table of eclipse dates which used one calendar for eclipses
before 1582 and a different calendar for eclipses after 1582 would be
worse than a table which used dates exclusively from either one
calendar or the other.
Also I think it is misguided to attempt to mirror in computer code the
historical process of the conversion in different countries from the
old calendar to the new (for details see
Thus I suggest that instead of a class for a 'fused' Julian-Gregorian
Calendar, it would be better either (a) to have one class for the
Proleptic Julian Calendar and one class for the Proleptic Julian
Calendar, or (b) one class which accommodates date conversion and date
arithmetic in both calendars simply by using a flag 'G' or 'J'
indicating which (proleptic) calendar is to be used. I think (b) would
be more economical, since only one class is needed.
|Free forum by Nabble||Edit this page|