Front page | perl.datetime |
Postings from January 2003
Re: Picking up the ball
From: Matt Sergeant
January 10, 2003 05:22
Re: Picking up the ball
Message ID: Pine.LNX.4.44L.firstname.lastname@example.org
On Fri, 10 Jan 2003, Dave Rolsky wrote:
> On Fri, 10 Jan 2003, Matt Sergeant wrote:
> > What I want to see is a Time::Piece based on Date::Ical (or if that becomes
> > DateTime.pm then fine). I've wanted that since I read the Pod for
> > Date::Ical and realised (like David and Dave have) that it's not just for
> > the ICal format - it's actually a very nice base class for datetime issues.
> > Mostly this should be a trivial task. The only hairy issues I can see are
> > the fact that some of the stuff is C based using struct tm's. I don't know
> > if stuct tm's can go outside of the epoch seconds range. Does anyone else?
> > The other thing is that the return from strptime is re-adjusted in C by
> > turning it into an epoch time and then back into a proper time. But I'm sure
> > that can also be gotten around.
> > So - any volunteers to take over Time::Piece? (or supply me with a whopping
> > great patch?)
> My first concern is with API, no implementation. If it's easier to whip
> together a quick strptime in Perl, I'd probably prefer to do that. What I
> like most about Time::Piece is its API, not the particulars of its
> implementation. In fact, it's implementation is obviously problematic
> (array-based object, C bits, etc.). Moreover, it looks like the tm struct
> it uses does not support non-epoch times, so it's definitely not feasible
> to reuse that code.
Don't throw out the baby with the bathwater. There's some good things
going for Time::Piece right now:
1. It has a *lot* of users.
2. It has quite a bit of good and mostly reusable code.
3. It's the API blessed/designed by Larry Wall (that may or may not be a
good thing ;-)
4. The API can support non-epoch times, so changing the internals should
be invisible to the user.
Just because the internals are a little screwey doesn't mean we shouldn't
just retrofit it to a Date::ICal backend. I see no reason not to do that,
rather than starting again from scratch.
The other thing being that the whole datetime area is a huge piece of
work, and is really hard to understand the finer points of the little
corners of it. And if you get it wrong you screw up people's software in
really hard to debug ways. What I'm saying here is we don't really have
the manpower/money to just scrap everything and start again.
<!-- Matt -->
<:->get a SMart net</:->
Spam trap - do not mail: email@example.com