From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu Oct 20 2005 - 17:13:29 CST
From: "Edward H. Trager" <ehtrager@umich.edu>
> Hi, Stephen,
>
> This sounds like a difficult project when you consider how many holidays
> in many parts of the world are based on lunar calendar calculations, and
> so
> on. So, although it may make sense to work with CLDR for the subset of
> holidays
> that can be pegged to the Gregorian Solar-based calendar, you are also
> going
> to need to look quite seriously at all of the calendar calculation
> programs
> out there. But probably you guys are already aware of this. If you are
> interested
> in some additional resources, email me off-list and I will try to find the
> various references on calendar stuff that I have used previously.
Even for the Easter day calculation there are difficulties, because various
churches do not apply the same rules for the same year, and they changed
these rules over time (some accepting astronomical adjustments at one time,
or continuing with some orthodoxy with the historic rules).
Human calendars are a complex issue, and until a good external reference is
made that reaches some consensusand stability, there's little chance that
such rules will be included in the CLDR. Those rules must first be
experimented, and the data format will still need to be adapted and changed.
We certainly don't need too much instability in the data schemas for the
CLDR. So it's still best to develop external data schemas, and allow
applications to use the schemas that meet their requirements.
So go on with the joda-time open-source project, and until it has reached
some recognized level of stability, it may get acceptance (for example the
timezone database in CLDR comes from the patiently built Olson's database
whose format was adapted until it met some concensus and was judged enough
viable to become part of a common localization data such as the CLDR, before
that, all OSes where integrating more or less successfully their own rules.
It's still not perfect or not well implemented in operating systems that
have their own caveats in the way they repesent the timezone data to
applications using them, for example in Windows where the API is not
consistant enough to represent all cases...).
This archive was generated by hypermail 2.1.5 : Thu Oct 20 2005 - 20:05:16 CST