FAQ
Here's my initial discussion and proposal re namespace issues. I'd
really like to have a show of hands from the people that this most
affects - at least initially - which is you guys. Eventually, this
affects the users, of course, but we can manage the process in such a
way that it is not too painful for them. There has been some
discussion about how that is to be handled also.

--
Rich Bowen - rbowen@rcbowen.com
ReefKnot - http://www.reefknot.org

---------- Forwarded message ----------
Date: Mon, 6 Aug 2001 23:20:35 -0400 (EDT)
From: Rich Bowen <rbowen@rcbowen.com>
To: datetime <datetime@perl.org>
Subject: Namespace issues

One of the issues that I had hoped to discuss on this list was the
issue of namespaces. There are two major ones.

First, there's the Time:: vs Date:: issue. That is, there are Time::
modules, and there are Date:: modules, and there's no consistent
definition of what goes in which. An appeal to modules@perl.org for a
little direction on this matter did not produce a particularly helpful
answer, and so it seems up to the authors of these modules to make
sensible choices.

I'd like to have some discussion as to what people think these
namespaces mean, and then to request that authors respect those
definitions, and, if a particular module is not in the namespace that
it should be, that it migrate to the correct namespace via a
several-month period of adding warnings to modules, asking people to
move to the new version of the module in the new namespace.

The second issue is one of de-cluttering the modules that are already
there. Yes, I know that I'm one of the main culprits, cluttering the
Date:: namespace with all of the things that I've written for my own
mathematical amusements. But I'm also very willing to change, and move
these modules elsewhere.

What I'd like to propose here is a namespace hierarchy where modules
get put in places that reflect their purpose. Something like, perhaps:

Date::Algorithm - Modules that do things like calculate leapyears,
calculate golden numbers, calculate epacts, full moons, and so on. So
Date::Leapyear would become Date::Algorithm::Leapyear, for example.

Date::Calendar - Modules that implement a particular (usually
non-Gregorian) calendar. So Date::Discordian would become
Date::Calendar::Discordian

Date::Holiday - Modules that calculate the date of a particular
holiday. So Date::Easter becomes Date::Holiday::Easter

There are also a variety of things that purport to be the One True
Module that should be the base class for all Date:: and Time::
modules. There are at least 4 of these that I know of. And I wrote one
of them. All of them have shortcomings. These folks need to get
together and compromise on some things, so we can actually have one of
these that doesn't suck, and which people can agree on.

And then there are the standards like Date::Manip and Date::Calc. They
should probably just stay where they are. I think that a certain
amount of duplication is inevitable when there are monolithic modules
like these two which do EVERYTHING. They are great modules. They're
just a little heavy.

On a related note, I'm working on lists of all the Date:: and Time::
modules (yeah, I know, you can just do an ls in your CPAN mirror) and
trying to understand what they all do, where there is overlap, and
where various authors aught to get together and cooperate on some
things. I know, this is like herding cats, but it keeps me off the
streets.

Please let me know what your thoughts are on these things. And let me
know that I'm not just talking to myself on this list.

--
Rich Bowen - rbowen@rcbowen.com
Author - Apache Server Unleashed - http://www.apacheunleashed.com/

Search Discussions

  • Hill, Ronald at Aug 23, 2001 at 2:46 pm

    Here's my initial discussion and proposal re namespace issues. I'd
    really like to have a show of hands from the people that this most
    affects - at least initially - which is you guys. Eventually, this
    affects the users, of course, but we can manage the process in such a
    way that it is not too painful for them. There has been some
    discussion about how that is to be handled also.

    ---------- Forwarded message ----------

    One of the issues that I had hoped to discuss on this list was the
    issue of namespaces. There are two major ones.

    First, there's the Time:: vs Date:: issue. That is, there are Time::
    modules, and there are Date:: modules, and there's no consistent
    definition of what goes in which. An appeal to modules@perl.org for a
    little direction on this matter did not produce a particularly helpful
    answer, and so it seems up to the authors of these modules to make
    sensible choices.
    I agree with this. Anything that deals with days or any greater
    unit goes in Date, anything that only deals with smaller units goes
    in Time. Also, there was some discussion about putting together an SDK
    for the date/time namespace. I think that was a great idea!!

    [snipped]
    The second issue is one of de-cluttering the modules that are already
    there. Yes, I know that I'm one of the main culprits, cluttering the
    Date:: namespace with all of the things that I've written for my own
    mathematical amusements. But I'm also very willing to change, and move
    these modules elsewhere.
    Cleanup is always a good thing!!
    What I'd like to propose here is a namespace hierarchy where modules
    get put in places that reflect their purpose. Something like, perhaps:

    Date::Algorithm - Modules that do things like calculate leapyears,
    calculate golden numbers, calculate epacts, full moons, and so on. So
    Date::Leapyear would become Date::Algorithm::Leapyear, for example.

    Date::Calendar - Modules that implement a particular (usually
    non-Gregorian) calendar. So Date::Discordian would become
    Date::Calendar::Discordian

    Date::Holiday - Modules that calculate the date of a particular
    holiday. So Date::Easter becomes Date::Holiday::Easter
    I agree, In my case it would be Time::Algorithm::Sunrise.
    [snipped]
    On a related note, I'm working on lists of all the Date:: and Time::
    modules (yeah, I know, you can just do an ls in your CPAN mirror) and
    trying to understand what they all do, where there is overlap, and
    where various authors aught to get together and cooperate on some
    things. I know, this is like herding cats, but it keeps me off the
    streets.
    This issue, I feel is the first thing that needs to happen. We need a
    current list of date/time modules so we know where we stand. Does
    anyone have such a list? Have all the authors been contacted?

    Ron Hill
  • Kirrily Robert at Aug 23, 2001 at 4:53 pm

    In perl.datetime, you wrote:
    This issue, I feel is the first thing that needs to happen. We need a
    current list of date/time modules so we know where we stand. Does
    anyone have such a list? Have all the authors been contacted?
    Yes and yes. You can find this information at
    http://infotrope.net/opensource/software/perl6/modules/author-groups/datetime/

    K.

    --
    Kirrily 'Skud' Robert - skud@infotrope.net - http://infotrope.net/
    Heavily armed, easily bored, and off my medication.
  • Steffen Beyer at Aug 23, 2001 at 2:47 pm

    Hello Rich Bowen, in a previous mail you wrote:

    First, there's the Time:: vs Date:: issue.
    I'd like to have some discussion as to what people think these
    namespaces mean, [...]
    IMHO, Date:: modules should predominantly deal with dates, i.e.,
    years, months, days, weeks, days of week, all that stuff.
    Time:: modules should predominantly deal with time, i.e.,
    hours, minutes and seconds.
    Of course there are border cases, for instance modules that
    deal with seconds since the epoch for date calculations.
    Maybe there should be a "DateTime::" namespace for modules
    that deal with both.
    What I'd like to propose here is a namespace hierarchy where modules
    get put in places that reflect their purpose.
    [...]
    Sounds good, but be aware that there are always modules which won't
    fit into any category scheme...
    And then there are the standards like Date::Manip and Date::Calc. They
    should probably just stay where they are. I think that a certain
    amount of duplication is inevitable when there are monolithic modules
    like these two which do EVERYTHING. They are great modules.
    Thanks a lot for your high esteem! :-)
    They're just a little heavy.
    I have to disagree. :-)
    The Date::Calc 5.0 shared object library is just 77505 bytes in length
    on my FreeBSD system (and the Date::Calc 5.0 Perl wrapper is only 8318
    bytes in length). This is probably less than many of the date modules
    written in plain Perl!
    Please let me know what your thoughts are on these things. And let me
    know that I'm not just talking to myself on this list.
    There you are. :-)

    BTW, the upcoming new release of Date::Calc version 5.0 will contain
    modules for date calculations that take holidays into account (after
    too many people asked for this feature, I finally gave in and wrote
    it). These modules are called Date::Calendar, Date::Calendar::Year
    and Date::Calendar::Profiles.

    I hope these names are okay for you, because I probably wouldn't even
    have the time to change them if not. For private reasons, this will
    probably be the last major release for a long, long time, and I will
    probably only have about enough time to just finish version 5.0 (a few
    parts of the documentation are lacking).

    If you'd like to take a look at the current state of affairs, direct
    your browser to
    http://www.engelschall.com/u/sb/download/pkg/Date-Calc-5.0.tar.gz

    Best regards,
    --
    Steffen Beyer <sb@engelschall.com>
    http://www.engelschall.com/u/sb/whoami/ (Who am I)
    http://www.engelschall.com/u/sb/gallery/ (Fotos Brasil, USA, ...)
    http://www.engelschall.com/u/sb/download/ (Free Perl and C Software)
  • Rich Bowen at Aug 23, 2001 at 4:55 pm

    On Thu, 23 Aug 2001, Steffen Beyer wrote:

    And then there are the standards like Date::Manip and Date::Calc. They
    should probably just stay where they are. I think that a certain
    amount of duplication is inevitable when there are monolithic modules
    like these two which do EVERYTHING. They are great modules.
    Thanks a lot for your high esteem! :-)
    They're just a little heavy.
    I have to disagree. :-)
    The Date::Calc 5.0 shared object library is just 77505 bytes in length
    on my FreeBSD system (and the Date::Calc 5.0 Perl wrapper is only 8318
    bytes in length). This is probably less than many of the date modules
    written in plain Perl!
    OK, my error. I will correct my thinking. I suppose that for a long
    time I had Date::Calc and Date::Manip confused in my brane, and some
    of that confusion lingers.
    BTW, the upcoming new release of Date::Calc version 5.0 will contain
    modules for date calculations that take holidays into account (after
    too many people asked for this feature, I finally gave in and wrote
    it). These modules are called Date::Calendar, Date::Calendar::Year
    and Date::Calendar::Profiles.

    I hope these names are okay for you, because I probably wouldn't even
    have the time to change them if not.
    Well, the only problem I have with these names is that they get in the
    way of the very attempt at namespace standardization that this thread
    is all about. If the Date::Calendar namespace is to be for calendars
    (ie non-gregorian calendars such as Bah'ai, French Revolution, etc)
    then this not only is in the wrong namespace, but stand squarely in
    the way of having the namepace in the first place.
    If you'd like to take a look at the current state of affairs, direct
    your browser to
    http://www.engelschall.com/u/sb/download/pkg/Date-Calc-5.0.tar.gz
    Thanks. I am definitely interested. I'll dl that and look at it.
    Thanks for the preview.

    --
    Rich Bowen - rbowen@rcbowen.com
    As we trace our own few circles around the sun
    We get it backwards and our seven years go by like one
    Dog Years (Rush - Test for Echo - 1999)
  • Steffen Beyer at Aug 24, 2001 at 10:31 am

    Hello Rich Bowen, in a previous mail you wrote:

    They're just a little heavy.
    I have to disagree. :-)
    [...]
    OK, my error. I will correct my thinking. I suppose that for a long
    time I had Date::Calc and Date::Manip confused in my brane, and some
    of that confusion lingers.
    No problem. Looks like this is fixed now, isn't it?! ;-)
    These modules are called Date::Calendar, Date::Calendar::Year
    and Date::Calendar::Profiles. I hope these names are okay for you?
    Well, the only problem I have with these names is that they get in the
    way of the very attempt at namespace standardization that this thread
    is all about. If the Date::Calendar namespace is to be for calendars
    (ie non-gregorian calendars such as Bah'ai, French Revolution, etc)
    then this not only is in the wrong namespace, but stand squarely in
    the way of having the namepace in the first place.
    Ok, I agree.
    So please make suggestions of better names!

    However, in order to make the name change as simple as possible, please
    try to just find a substitute for the "Calendar" part of the name. It
    would make things a lot easier (to change) if the rest of the names
    stayed the same. And if possible, please let's settle this question
    quickly, as I'm currently in the process of finishing the new version.
    Thank you all very much in advance!
    If you'd like to take a look at the current state of affairs, [...]
    http://www.engelschall.com/u/sb/download/pkg/Date-Calc-5.0.tar.gz
    Thanks. I am definitely interested. I'll dl that and look at it.
    Thanks for the preview.
    You're welcome. Thanks for the interest!!

    Best regards,
    --
    Steffen Beyer <sb@engelschall.com>
    http://www.engelschall.com/u/sb/whoami/ (Who am I)
    http://www.engelschall.com/u/sb/gallery/ (Fotos Brasil, USA, ...)
    http://www.engelschall.com/u/sb/download/ (Free Perl and C Software)
  • Ilmari Karonen at Aug 24, 2001 at 9:10 pm

    On Fri, 24 Aug 2001, Steffen Beyer wrote:
    Ok, I agree.
    So please make suggestions of better names!

    However, in order to make the name change as simple as possible, please
    try to just find a substitute for the "Calendar" part of the name. It
    Okay, how about s/Calendar/Calc::Calendar/? That will put them under
    your "own" namespace, which I'm sure nobody would object to.

    If you want to avoid four-level names, remove "Calendar" from the last
    two. Or something..

    --
    Ilmari Karonen - http://www.sci.fi/~iltzu/
    "This leads me to suspect that most people don't understand half of
    what I say but pretend nothing's wrong. Fortunately for me, I can
    live with that." -- John Kensmark in rec.arts.sf.composition
  • Kirrily Robert at Aug 24, 2001 at 3:45 pm

    In perl.datetime, you wrote:
    IMHO, Date:: modules should predominantly deal with dates, i.e.,
    years, months, days, weeks, days of week, all that stuff.
    Time:: modules should predominantly deal with time, i.e.,
    hours, minutes and seconds.
    Of course there are border cases, for instance modules that
    deal with seconds since the epoch for date calculations.
    Maybe there should be a "DateTime::" namespace for modules
    that deal with both.
    Nooooooo!

    I think that would cause more confusion.

    The confusion between Date/Time stems from the overlap space... so why
    not just say that "anything that deals with units of a day or greater
    goes in Date, anything that NEVER deals with days or greater goes in
    Time" ... and define "deals with" as "accepts parameters, or returns
    values, which represent those units" (the black box approach -- doesn't
    matter what the module does internally).

    Hence a module with a method which accepted seconds-since-epoch and
    returned a Frobnitzian calendar day would go into Date. On the other
    hand, a module which accepted seconds-since-Unix-epoch and returned
    seconds-since-VMS-epoch would go into Time.

    K.

    --
    Kirrily 'Skud' Robert - skud@infotrope.net - http://infotrope.net/
    "Ultimately thread drift is limited by how far you can drift from the topic
    of sex. Every thread ends up there eventually, more so in here than many
    other places." -- Joe Thompson in a.s.r
  • Ilmari Karonen at Aug 24, 2001 at 9:20 pm

    On Fri, 24 Aug 2001, Kirrily Robert wrote:

    The confusion between Date/Time stems from the overlap space... so why
    not just say that "anything that deals with units of a day or greater
    goes in Date, anything that NEVER deals with days or greater goes in
    Time" ... and define "deals with" as "accepts parameters, or returns
    values, which represent those units" (the black box approach -- doesn't
    matter what the module does internally).
    I agree, but with some fine-tuning: Time modules that accept "1D" as a
    synonym for 86400 seconds should IMHO still go under Time::, even though
    they "deal with units of a day".

    I think the idea is clear, I just can't come up with a waterproof way of
    specifying the split. "Modules that deal with units greater than a day,
    or do not deal with units less than a day, belong in Date::"???

    Hence a module with a method which accepted seconds-since-epoch and
    returned a Frobnitzian calendar day would go into Date. On the other
    hand, a module which accepted seconds-since-Unix-epoch and returned
    seconds-since-VMS-epoch would go into Time.
    Sounds just about right to me.

    --
    Ilmari Karonen - http://www.sci.fi/~iltzu/
    "Wheel-reinventing is naturally a pain in numerous places, but since our
    existing wheels are hexagonal and the new ones we're making are round,
    it's well worth it." -- Dan Birchall in the monastery
  • Srl at Aug 24, 2001 at 11:33 pm

    On Sat, 25 Aug 2001, Ilmari Karonen wrote:
    On Fri, 24 Aug 2001, Kirrily Robert wrote:
    I agree, but with some fine-tuning: Time modules that accept "1D" as a
    synonym for 86400 seconds should IMHO still go under Time::, even though
    they "deal with units of a day".
    <pedant>

    In calendaring terms, a day is not reliably 86400 seconds. Because
    of daylight savings time, some days are 86400-(60*60) seconds long,
    and some are 86400+(60*60) seconds long. If you have a module that
    makes this assumption, you should state in your documentation
    how/whether it behaves properly when spanning DST switchovers.

    And then there are leap seconds....

    </pedant>

    On a more serious note: is there any reliable knowledge about how
    Perl on various platforms behaves if it's running during the moment
    of a DST switchover?

    srl, ducking and running
    --
    Shane R. Landrum slandrum@cs.smith.edu
    we generate our own light to compensate for the lack of light from above -AD
    GPG public key: http://cs.smith.edu/~slandrum/srl_pgpkey.txt
  • David Cantrell at Aug 25, 2001 at 12:21 am

    On Fri, Aug 24, 2001 at 07:34:19PM -0400, srl wrote:
    On a more serious note: is there any reliable knowledge about how
    Perl on various platforms behaves if it's running during the moment
    of a DST switchover?
    It Does The Right Thing. Remember, Unixy time is not measured in hours
    minutes and seconds, but in seconds since the epoch. This is independent
    of timezone and of any silly local offsets from the time zone.

    --
    David Cantrell | david@cantrell.org.uk | http://www.cantrell.org.uk/david

    Educating this luser would be something to frustrate even the
    unflappable Yoda and make him jam a lightsaber up his arse
    while screaming "praise evil, the Dark Side is your friend!".
    -- Derek Balling, in the Monastery
  • Abigail at Aug 23, 2001 at 6:04 pm

    On Thu, Aug 23, 2001 at 09:47:04AM -0400, Rich Bowen wrote:

    I'd like to have some discussion as to what people think these
    namespaces mean, and then to request that authors respect those
    definitions, and, if a particular module is not in the namespace that
    it should be, that it migrate to the correct namespace via a
    several-month period of adding warnings to modules, asking people to
    move to the new version of the module in the new namespace.
    No, I'm not going to do this that easily. Apart from the question what
    the various namespaces would mean, I'd like to be convinced there's
    something to gain to move existing modules to a different namespace.
    It's certainly not nice for your users.
    The second issue is one of de-cluttering the modules that are already
    there. Yes, I know that I'm one of the main culprits, cluttering the
    Date:: namespace with all of the things that I've written for my own
    mathematical amusements. But I'm also very willing to change, and move
    these modules elsewhere.

    What I'd like to propose here is a namespace hierarchy where modules
    get put in places that reflect their purpose. Something like, perhaps:

    Date::Algorithm - Modules that do things like calculate leapyears,
    calculate golden numbers, calculate epacts, full moons, and so on. So
    Date::Leapyear would become Date::Algorithm::Leapyear, for example.

    Date::Calendar - Modules that implement a particular (usually
    non-Gregorian) calendar. So Date::Discordian would become
    Date::Calendar::Discordian

    Date::Holiday - Modules that calculate the date of a particular
    holiday. So Date::Easter becomes Date::Holiday::Easter
    So, where does that leave Date::Maya? It certainly doesn't "implement"
    a calendar (although I'm not sure what you mean by implementing a
    calendar). It only converts from Mayan dates to Julian days (and in
    reverse).

    I also wonder whether it's a good idea to make the Gregorian calendar
    special. Why wouldn't it be "Date::Algorithm::Gregorian::Leapyear"?
    After all, the Julian calendar has leapyears too - a module for that
    shouldn't be called "Date::Algorithm::Leapyear".

    Some calculations are completely calendar independent - like when it
    is full moon. Other calculations are completly calendar dependent;
    golden numbers for instance. I don't it's wise to have a namespace
    framework that's oblivious of the difference.

    Date::Holiday doesn't sound like a useful namespace to me. There is a
    set of modules that calculate the date/time of events. Like full moon
    or Christmas. Some events happen to be holidays (in some parts of the
    world), but I don't think that should be reflected in the name space.
    Why not "Date::Event"? But then, a module that would return the next
    leapday in the Gregorian calendar, should that go under Date::Algorithm,
    or Date::Event?



    Abigail
  • Tom Braun at Aug 25, 2001 at 3:09 am
    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
  • Ilmari Karonen at Aug 25, 2001 at 9:48 am

    On Fri, 24 Aug 2001, Tom Braun wrote:
    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
    This is *not* an argument for *or* against your proposal, just an
    observation: Even if this is done, some modules will remain in Time::
    since it makes no sense to associate them with any mention of dates.
    Time::HiRes comes to mind, as does my own little Time::Stopwatch.

    --
    Ilmari Karonen - http://www.sci.fi/~iltzu/
    "I'm just saying that I don't think it's any more or less appropriate to
    condemn prostitution than it is to condemn, say, Andersen Consulting.
    Tempting though that may be." -- Matt McLeod in the monastery
  • Kirrily Robert at Aug 25, 2001 at 4:46 pm

    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 - skud@infotrope.net - 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)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedAug 23, '01 at 1:47p
activeAug 25, '01 at 4:46p
posts15
users9
websitemetacpan.org...

People

Translate

site design / logo © 2019 Grokbase