Sorry the late reply. Vacations and stuff ...
On Fri, Aug 10, 2001 at 12:52:31PM -0400, [EMAIL PROTECTED] wrote:
> I'm contacting as many authors of date and/or time modules on CPAN as I
> can find. A look at search.cpan.org identifies you as the
> author/maintainer of:
>
> Date::Time
Hm ... funny :-) Long time ago, and I've forgotten most of it.
I tried starting some discussion at the Perl module newsgroup about the
messy and sorry state the Date and Time namespace is in, and the lack of any
object oriented package.
I did have some strong viewpoints. Some few of those was taken into
consideration in the Time::Object and Date::Calc packages, as far as I can
remember.
I made some halfly complete package. I don't remember if it ended up at
CPAN at all. Some student helped me a bit, he thought "Date::Kronos" was a
good name. I dislike that name a bit, but eventually I ended up with
something named Date::Kronos. I think it got a bit too complex, but it is
somewhere near to what I want it to be. I'd gladly maintain and support the
package - but only if there are users behind it, and I'm not going to do any
marketing effort.
Unfortunately my laptop got stolen. Some old sources, but still probably a
lot more up to date than what eventually exists at CPAN, should be at
sourceforge - search for oo-datetime. I might eventually try to locate it
myself.
Date::Kronos basically mirrors some of my strong viewpoints towards dates
and times:
1. There is a certain need of a generic object oriented time/date class. For
one thing, it could reduce the need of orienting in the current
time/date-jungle at CPAN. Some programmer that wants some functionality
without too much fuzz should just install the generic class - and all
functionality from all the other modules should be available as methods on
the object. It might sound too damn bloaty, but I think it scales pretty
well - after all, perl has the autoload possibility.
2. A generic object oriented time/date class should not be too biased
towards the Gregorian calendar, nor towards our time units (hours, minutes
and seconds). Personally, I think the Gregorian calendar sucks big time.
Unfortunately, it is the international de-facto standard. Anyway, we
shouldn't forget that the Gregorian representation _only_ is needed when a
program is to communicate with an end user.
3. The internal representation of a date might differ - both in type as well
as semantics. Different representations makes sense in different contexts.
In an object oriented setting, we should not do guesswork about the context
- hence, a date in a given type should not be converted or parsed until it's
actually necessary.
Date::Time at CPAN is just some namespace, there is no package behind it, as
far as I can remember? I can give it away as long as I can agree to some
consent about what it will be. Or it can be used for more development on
the current Date::Kronos package.
> We're trying to gather as many date/time module authors as possible on
> the [EMAIL PROTECTED] mailing list to discuss a range of issues
> including:
Count me in! I made some mailing list at sourceforge about it. You might
try to ask people there to join the new mailing list.
As your mailing list probably has existed for some weeks, I'd be happy to
get some short summary of the activity so far.
If you want to discuss any of my viewpoints, please forward this mail or the
interessting parts of it to the mailing list, and continue the discussion
there.
