In perl.datetime, you wrote:
>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.
Pet peeve:
Either Date::Mayan and Date::Gregorian, or else Date::Maya and
Date::Gregory.
>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.
Ugh. Yuk. I much prefer Rich's suggestion of having (as far as
possible, among those authors who want to buy into it) a common internal
representation of dates and times so we can rebless one date date object
into another class.
>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).
Rich also proposed iCalendar time, which is a nice human-readable and
easily-parsable format. Check the archives for that one.
>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.
This is not a bad idea.
>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.
This argument makes good sense to me.
K.
--
Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/
"I have to say that the word 'compliant' is not one which it would ever
occur to me to apply to our Skud."
-- Lionel Lauer, on a.s.r (from the Netizen quotes file)
