Perhaps there is another approach to consider. Rather than a Date::foo for
each type of module, what about a subcategory for each calendar?
For example, the Mayan calendar would remain Date::Maya. However, any
modules that do calculation with the Mayan calendar would be
Date::Maya::foo. A module that calculates leap years for the Gregorian
calendar would be Date::Gregorian::Leapyear. A general Date::Algorithm::
category could also be retained for calendar independent events, such as
calculating full moons.
There are some modules that deal with two or more calendars beyond the
standard two I've suggested we implement. In this case, we can either put
them under the general Date::Algorithm:: section if it works with many
calendars, or put it under both calendars. This creates a few more modules,
or more precisely, a few more stubs pointing to other modules. It does,
however, keep things as simple as possible for the users. Thus, if I wrote
a module to convert between Date::Tolkien::Shire and Date::Discordian (both
of whose names would remain the same under these proposals), it would be
named something to the effect of Date::Discordian::ShireConvert and
Date::Tolkien::Shire::DiscordianConvert (one would be a stub to the other,
with appropriate name changes to make the methods intuitive to the calendar
in question). Of course, I can't think why I'd want to do this with these
two calendars, but it serves as an example.
>From earlier talk it sounds like the standard time/calendar formats that we
agreed on are JulianDay and unix epoch seconds (since this is what commands
like time return). I further propose that all calendar modules be made to
handle date conversion from/to these two standard formats (I still have to
add Julian support to me own). This give a standard for easy conversion
without the need for 50 zillion convert modules. And since these are
assumed, a need to specify a Date::Discordian::JulianConvert is unnecessary.
The first proposal allows us to organize all the date modules, which is what
all this started as in the first place. It also makes calendar modules
easier to use. If I know I need to deal with a certain calendar, I can
easily find and get all modules that deal with this calendar. I can also
tell instantly from a module name what calendar it supports, and potentially
can use CPAN.pm to install all such modules at once. The second proposal
allows a user to know he can go from one calendar to another without jumping
through a lot of hoops.
Finally, and as a completely seperate proposal, I'll put in my two cents
worth on the Date:: and Time:: controversy. What if we slowly phased out
both Date:: and Time::, and migrate all modules slowly to a DateTime::
category. Modules that meet the standard we agree on, once we agree on one,
will go in DateTime::, and their ancestors will be deprecated. If we're
moving names anyway, why not remove this controversy completely and at the
same time avoid any instances of a module name we want to use already
existing as something else. Further, it makes sure that existing modules
keep working with existing code, because no module in the existing hierarchy
will be changed.
Humbly yours,
Tom
