[mplspm]: A project for MPM

[Brian Parker]

I think this is a great idea.  Having just spent quite a bit of time try to
find the "best" date/time module, I know their is definitely a need to be
met.  (We ended up using both Class::Date and Date::Calc.)

I definitely will volunteer some amount of time.  I have to weigh my time
commitments before I ask for a large chunk of the work.  (We just had a baby
girl.)

Would we use pod for this?  Would the format be similar to the poop doc:
http://poop.sourceforge.net/

regards,
Brian

----- Original Message -----
From: "Dave Rolsky" <autarch at urth.org>
To: <mpls at pm.org>
Sent: Tuesday, October 29, 2002 10:51 PM
Subject: [mplspm]: A project for MPM


> So we've talked a bit about this in the past, and at the last meeting we
> briefly mentioned the idea of taking on dates & times as our PM project.
>
> I think this'd be a really cool thing to do, and there is a desperate need
> for somebodies in the Perl community to really try to improve the
> situation in regards to date/time modules.
>
> Here's some thing that I think we could work on, in order of increasing
> difficulty.
>
> 1. A document comparing all the major date & time modules for Perl.
>
> Things to look at could include:
>
> -- module scope (how much stuff it does)
> -- epoch only or not?
> -- does date math?
> -- OO or functions?
> -- special features?
> -- license
> -- strengths/weakness (somewhat subjective but that's ok)
>
>
> 2. Take the above and turn it into datetime.perl.org.  This could be a
> website we collectively maintained that hosted the above document and
> perhaps other resources (I'm not sure exactly what though).
>
>
> 3. Fill in the gaps.  For example, AFAIK there is no module for Perl that
> handles time zones completely and correctly.  In fact, the only module I
> know of for Perl that handles time zones at all is Time::Zone, which AFAIC
> is close to useless.  All it does is parse Unix-style TZ env variables and
> return offsets.  That's not very helpful because it uses the older style
> 3/4 letter zones like 'cst', which just doesn't cut it these days.
>
>
> 4. Try to come up with _the_ one way to do it ;)  I say this sort of
> tongue in cheek, but only sort of.  Perl has a lot of different date/time
> modules, each of which individually have very interesting and useful
> features, but none of which by itself does everything.  Since they all
> have radically different interfaces, working with more than 1 module at a
> time is a big pain in the ass.
>
> Initially, we might just try to design a single interface that hides the
> details of the different modules, and presents a single unified way of
> doing all the useful things one could do (parsing, date math, output in
> different formats, etc.).  Later, we might start actually ripping code out
> of different modules and putting together our own suite of modules that
> represents the best of Perl's date/time code.
>
>
> If there's any takers for #1, here's a reasonably complete list of
> "interesting" Perl date/time modules along with my comments about them:
>
>
> - Time::Piece (and Time::Seconds) - nice interface, nice simply date math,
> but only handles epoch times, which is a drag.  See also my
> Time::Piece::MySQL module, which adds some mysql-specific bits.  Similar
> modules for other DBs/external resources can be added just as easily.
>
> - Class::Date & Date::Handler - kind of like Time::Piece on steroids, but
> I don't see why they can't all be integrated.
>
> - Date::Manip - ridiculously large amount of code.  crapulous interface.
> freaking brilliant parsing code that handles things like "2nd day after
> next Tuesday" or "the first day of the last week of the next month".  Also
> has some internationalization bits for parsing, which is doubly slick.  If
> this thing could return a Time::Piece object (and T::P handled times
> outside of the epoch), I'd be in heaven.
>
> - Date::Calc - lots of nice date math functions.  Stupid interface
> (Function_Names_Like_This).  Written in C so presumably its fast.
>
> -- Date::Calc::Object - OO interface over Date::Calc.  Interesting.  Also
> has Date delta objects.  Cool!  Works with Date::Calc functions, which
> have stupid names, but making a wrapper for that wouldn't be too hard.
>
> -- Date::Calendar - seems quite useful
>
> - Date::Parse - lightweight so it's a good choice if you know that you'll
> never exceed its limitations.  But those limitations are pretty big cause
> it doesn't do much.
>
> - Date::Format - basically strftime in Perl.  Time::Piece provides the
> same thing.
>
> - Time::Zone - see above
>
> - Time::Human - could be useful for some apps
>
> - Time::TAI64 - currently says not to use it, but it could provide
> something useful is author releases, stable, documented version.  Relies
> on libtai by Dan J Bernstein, known psycho.
>
> - Date::ICal - nice interface, would mesh well with Time::Piece.  ICal is
> important for calendaring apps.  Date::ICal is part of the reefknot
> project, which aimed at implementing all of iCal in Perl, but seems to be
> more or less defunct.
>
> - Date::Interval - could be interesting but seems to have a weird API.
>
>
> And quite a few more.  Also check out the now defunct reefknot project at
> www.reefknot.org, which has more resources on dates & times.
>
> So if people are interested perhaps they could pick a few modules to do
> writeups on.  I think something like this would be good:
>
>  scope: small, medium, big (how many different things it tries to
accomplish)
>  interface: OO / functions / both?
>  focus (or focii): parsing, output formatting, date math, business dates,
calendars, date intervals, etc.
>  license - important if we ever want to try to combine them
>
> And then maybe 2-4 paragraphs talking about special features, strengths
> and weaknesses, relationships to other modules.
>
>
> Any takers?
>
>
> -dave
>
> /*==================
> www.urth.org
> we await the New Sun
> ==================*/
>
>
>
>
>
> --------------------------------------------------
> Minneapolis Perl Mongers mailing list
>
> To unsubscribe, send mail to majordomo at pm.org
> with "unsubscribe mpls" in the body of the message.
>



--------------------------------------------------
Minneapolis Perl Mongers mailing list

To unsubscribe, send mail to majordomo at pm.org
with "unsubscribe mpls" in the body of the message.