develooper Front page | perl.datetime | Postings from January 2003

Re: Picking up the ball

Thread Previous | Thread Next
January 10, 2003 05:41
Re: Picking up the ball
Message ID:
On Fri, Jan 10, 2003 at 09:48:56AM +0000, Matt Sergeant wrote:
> On Fri, 10 Jan 2003, Dave Rolsky wrote:
> > 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.

No, I don't think Time::Piece is useful enough. It's too Gregorian
calendar oriented. It works quite well for relatively modern dates.
But it becomes messy for dates hundreds of years ago - not everywhere
did the switch to the Gregorian calendar happen at the same time.
And there are countries that don't even use the Gregorian calendar.

I think an internal format, and its API, should be based on something
universal. Something that not only makes sense everywhere, but also
at every point in time. Julian days for instance. This has the added
benefit that it's also a commonly used standard outside of the Perl world.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About