On this auspicious day of Poshi Poonam (full moon of the month of Pausha)
I would like to announce that I'm working on implementing various
Calendars traditionally used in India for the DateTime API.
It's something I've been fitfully working on for a few years now but
unlike previous abortive announcements, I actually having working code
this time :-)
However before I make an upload to CPAN, I would like some advice. I have
the following types of modules:
Indian calendars are of two types: solar, and luni-solar. There is a base
class for each type which would not be used directly but be subsclassed
for actual working calendars.
There is the actual calendars in historical and contemporary use
themselves.
There are modules for lunar and solar astronomical calculations.
Originally I used the existing DateTime::Util::Astro::* modules but they
are really slow and even worse give incorrect results. Whether this is
because of a bug in the modules, in my code or some weird math error (I
know perl has problems with this.) I don't know but the code I have now
(originally based on Jan Meeus's book.) is fast and gives me the correct
results. On the downside, it is a barely documented spaghetti mess so I
would eventually like to get it replaced with D::A::U if possible.
There are modules for localization into different Indian languages. The
existing DateTime::Locale framework can't be used because the units of
time measurement are different. (e.g. we have fortnights, leap months,
etc.)
So I was planning on using the following namespaces:
DateTime::Calendar::* - e,g. VikramaSamvata, ShalivahanaShakha etc.
The actual calendars people use.
DateTime::Calendar::Indic::* - e,g. Chandramana (luni-solar) Sauramana (solar)
The base classes for the calendars.
DateTime::Calendar::Indic::Util::* - e.g. Sun, Moon, Common
The support code for the calendars.
DateTime::Calendar::Indic::Locale::* - e.g. sn_utf8 (Sanskrit in UTF8),
gu_ITRANS (Gujarati in ITRANS transliteration) etc.
The i18n code for the calendars.
Does this seem ok?
--
Jaldhar H. Vyas <[EMAIL PROTECTED]>
