Front page | perl.datetime |
Postings from January 2003
Re: Picking up the ball
Thread Previous
|
Thread Next
From:
Rich Bowen
Date:
January 10, 2003 03:54
Subject:
Re: Picking up the ball
Message ID:
Pine.LNX.4.33.0301100617540.16060-100000@rhiannon.rcbowen.com
On Thu, 9 Jan 2003, Dave Rolsky wrote:
> [ CC'd to the Mpls Perl Monger list, Matt Sergeant, and David Wheeler, all
> of whom have expressed some interest in the topic. I'd suggest that
> further discussion be solely on the datetime@perl.org list, however. ]
Thanks, Dave, for doing this. This note clearly took some time, and has
more good ideas in it than I was able to express when I started ranting
about this 2 years ago, or whenever it was.
> Lots of discussion on this thread. I think Rich's basic points all still
> stand, and his ideas are all good. The only thing I think left out in
> Rich's proposal is that a base DateTime object should support fractions of
> a second. This could probably be optional, since most people won't need
> it.
Yes. Absolutely. Prolly because I tend to be more Date centered, than Time.
My interest is still, and probably will continue to be, non-Gregorian
calendars. Not because they are useful, but because they are
mathematically interesting. Squirreling them away into their own
namespace (like the proposed DateTime::Calendar) is a good idea - one
that I think I attempted at one point, but never got buy-in from the
other module authors.
> As a side note, there's a Perl interface to libtai64 called Time::TAI64
> (marked as beta and not updated in about 5 months). TAI64 is apparently
> the current standard, but I'm not sure that really means we have to use it
> ;)
This has been recommended to me by a bunch of people, but, alas, I have
never had the time to do a real thorough look-see of the standard. It
sounded good, though.
<More history snipped. Very good summary, though.>
> Rich says he gave up trying to herd the cats -
> http://archive.develooper.com/datetime@perl.org/msg00320.html
Also, some of the cats very adamantly stated that they had no interest
in being herded - that they *liked* being free-range cats.
> And last but not least, my recent rant in my use.perl journal about how
> this _still_ sucks, which prompted some discussion in the comments -
> http://use.perl.org/comments.pl?sid=10459
I missed that, but will go look.
> As part of the discussion I posted a quick proposal for fixing the mess,
> and I'll restate a refined version of that in a second.
>
> In a response to that proposal Jesse Vincent pointed out that there was
> code for timezones in the reefknot CVS as Date::ICal::TimeZone. Thanks
> Jesse!
Jesse is one of our great storehouses of good ideas and positive karma.
Yay Jesse. <subliminal>Everyone needs to use RT</subliminal>
> 1. Stop herding cats. If existing module authors don't want to play,
> then screw them. I don't want to spend lots of time arguing about
> namespaces and whether modules should move to a new namespace or any
> such crap. I want to have a suite of modules that actually work
> together, instead of a big mess of random crap!
In Apache Software Foundation parlance ...
+1
> 2. Use the DateTime:: namespace. The modules@perl.org cabal doesn't
> like it? That's nice. Their buy-in is nice, but lack thereof does
> not prevent success. And in my experience, when presented with
> working code that's being used by a bunch of people, they may accept a
> namespace previously deemed unacceptable.
>
> Why a new top-level namespace? Well, what's the difference between
> Date:: and Time::? Not much, in most cases. It seems like the
> authors of these modules mostly picked one at random. There are a few
> exceptions, like Time::HiRes, but other than that, it's ridiculous.
> Moreover, the DateTime:: space is empty except for one module, and so
> it won't be cluttered by a million overlapping older modules. So it
> provides a nice psychological benefit of dropping the baggage.
We could spend (ok, have spent) months arguing about name space. I
immediately came up with objections. But, you know, screw it. +1 on this
too. There is no perfect namespace. But once people start using it, it
will make sense to them.
One question. Does stuff like Time::HiRes stay in Time::? I think yes.
And there's other stuff that is less clear-cut where people will
complain and moan.
> 3. Start with set of base data objects around which functionality can be
> built.
>
> NOTE: I am not particularly wedded to any of these namespaces, I'm just
> trying to outline the basic functionality I think is needed for a good
> suite of datetime modules. OTOH, I don't want to spend lots of time
> arguing about the damn namespaces!
>
> - DateTime::Object - Yeah, I know Rich hates class names that describe
> the implementation, so maybe DateTime::Base.
Grumble Grumble Grumble. But, you know, if we can get working code, I'd
be in favor of Module::For::DateTime::Stuff. Ok, no, I wouldn't, but I
don't object that much any more. People would know what it meant, and
that's fine.
> I don't care too much. The
> namespace should make it should be obvious that this is the basic building
> block for all datetime functionality in the suite. A good candidate for
> this is the existing Date::ICal code, with a bunch of the Time::Piece
> convenience methods thrown in for good measure. The only thing Date::Ical
> needs is to add support for fractional seconds.
I like ICal. But let's make sure that Tai is not the better way to go before
we hack something onto an IETF (or whoever it is) standard. The fact
that it's a good idea does not mean that we should put stuff onto the
standard. The *primary* purpose of that module, and the Reefknot project
in general, is to implement standards in Perl. If the implementation
isn't standard, it's not right, and there might be some objections to
that from the Reefknot community as a whole. Dunno, we have not
discussed it yet. But that's my initial take.
> There's also Class::Date and Date::Handler. But I really want to recruit
> Rich for this, so I lean towards using a tweaked Date::ICal for the base
> object.
I am recruitable. I am, as my dear brother says, busier than a
one-legged man in a butt-kicking contest. But I am sufficiently stoked
about this that I could probably make time.
> -- Simple OO interface for getting pieces of the date, formatting for
> display, etc. Date::ICal and Time::Piece have a good API for this
> already. I think Time::Piece may have _too many_ methods, but Date::ICal
> doesn't have quite enough.
Comment as above. We can't break the ICal standard for our convenience.
Otherwise the name of the module would be misleading. One possibility,
of course, would be to have Date::ICal derive from DateTime::Object, and
then, I suppose, all my previous objections go away.
> -- It must work outside of epoch times. Date::ICal - check!
>
> -- It should handle fractional seconds. Based on a brief perusal of
> Date::ICal, I think this can be added without too much difficulty.
Sure.
> -- Provides simple date parsing ala Time::Piece->strptime. Maybe throw in
> the functionality provided by Date::Parse? Maybe make this a separate
> module. Doesn't matter too much.
modularization++
Part of the problem is too many GARGANTUAN modules that nobody - or
perhaps only one person - understands. Brilliant people are nice to have
around, but when they lose interest, and we inherit modules, it's nice
to understand them.
> -- Complex date parsing to be provided by a separate module (refactored
> Date::Manip, I hope).
>
> -- Real timezone support (Olsen database), something totally lacking in
> Perl right now. We need to finish up the Date::ICal::Timezone stuff Jesse
> pointed me at.
<barbie>Timezones are hard.</barbie>
I hate timezones.
But Jesse and Shane have nore timezone-fu than most other people, so we
should be in good hands.
> -- Date calculations ala Date::Calc. Some of what Date::Calc provides
> doesn't really return _dates_ per se, and that can go in a separate
> module.
Well, maybe. I think that "date calculations" is pretty broad, and is
covered by many of the other modules that you talk about. While it is
nice to have a single thingy that does all date calculations, it's
distinctly not nice to have 12 thingies that do a particular date
calculation in different ways. What day of the week is Christmas this
year? Well, there are 4 modules (currently, that I know of) that can
tell you this. Which one is better? Well, probably Date::Christmas,
because it is smaller and simpler. Or Date::Calc, because it does
everything else under the sun. Or Date::DayOfWeek, because it can tell
you what day of the week New Years is too. Or whatever that other one
was. *sigh*
> - DateTime::Delta - Date::ICal::Duration. Also look at some of the
> convenience constants provided by Time::Seconds (which comes with
> Time::Piece).
>
> -- Should handle business versus normal days.
There's a Date::Business, or something like that, that does an
interesting job of this.
> -- Should be possible to plug in holiday calendars for business day
> calculation. See Date::Calendar in Date::Calc.
This is hard. Very hard. The simplest way to say why it is hard is
"locale." Today, for example, is "Traditional Day" in Benin. And
tomorrow is "National Unity Day" in Nepal. Plus, days can be easy to
calculate, like Christmas, or slightly harder, like Thanksgiving, or a
lot harder, like Easter, or tons harder, like Ramadan or the Chinese New
Year.
However, it is also one of my special interests. The question of "what
is today", which seems so easy on the surface, is sufficiently complex
to spend your whole life on it.
> - DateTime::Set - See Date::Set
>
> -- Needs to handle both finite and infinite sets. Should allow set to be
> created as explicit set of DateTime::Object objects, _or_ via recurring
> specifier.
Set::Infinite I believe is a module that needs to be looked at.
> -- Should function as an iterator
>
> my $datetime = $dt_set->next;
>
> my $datetime = $dt_set->next( after => $datetime );
>
> my $datetime = $dt_set->next( before => $datetime );
>
> my $datetime = $dt_set->prev( before => $datetime );
>
> You get the picture.
Calendrical Calculations has some very nice stuff about this. I think it
would be very very *VERY* nice to invite Dr. Reingold and Derschowitz to
participate in this discussion. I have invited them before, and received
some very encouraging and courteous responses, but they are not Perl
guys. I'll drop them a note. This list is archived somewhere, right?
> -- Provide complex recurring specifier parsing, again this should probably
> come from a recfactored Date::Manip.
The "third thursday of every other month unless it's in Lent" kind of
thing?
> - DateTime::Span
>
> my $span = DateTime::Span->( begin => $datetime, end => $datetime );
> my $span = DateTime::Span->( datetime => $datetime, delta => $delta );
>
> if ( $span->contains( $some_datetime ) ) { ... }
>
> my $delta = DateTime::Span->delta;
Hmm. It seems that I've seen this code somewhere. I know that there is a
module out there that does this. OK, remind me, is the date object
always expected to be in our standard base class?
> - DateTime::Span::Set
>
> -- Whee! Sets of datetime spans! Again, finite and infinite.
>
> my $span = $dt_span_set->next( begins_before => $datetime );
Oh, cool. Can you give a real example? I'm getting woozy-headed.
> -- Complex parsing? "Every Tuesday in March from 3:30PM - 5:30PM" That'd
> be cool, but not crucial.
I think it's crucial. Sort of. Would make it easier to implement cron in
Perl. But then, I suppose someone has already done that.
> - DateTime::Algorithm - aka Rich's proposed Date::Algorithm. Includes
> things like:
>
> -- DateTime::Algorithm::Leapyear
> -- DateTime::Algorithm::Passover
Isn't that DateTime::Event::Passover?
> - DateTime::Calendar - other calendars
Yes, these are largely my doing. And while I don't expect anybody uses
any of them (except, of course, Discordian!) I'll probably keep grinding
them out, because they interest me. Quarantining them into their own
name space is a very good thing.
> -- Must be interoperable with base datetime object! This means that we
> can convert back and forth between the two on demand.
*happy sigh*
>
> -- DateTime::Calendar::Chinese
> -- DateTime::Calendar::Discordian
I have a number of these names "registered" from back when I had more
time on my hands. And I even have semi-functional code for many of them.
But moving them to the new namespace would be easy.
> - DateTime::Event - Rich proposed DateTime::Holiday but Abigail pointed
> out that there are plenty of events that aren't holidays, per se.
>
> -- DateTime::Event::Christmas
> -- DateTime::Event::Christmas::EasternOrthodox
> -- DateTime::Event::FourthofJuly - for _very_ dumb people ;)
Comment above. The "Algorithm" namespace may be superfluous.
I've got dibs on the FourthofJuly one, though. ;-)
> As noted in this proposal, much of this already exists. Here's the
> modules I propose stealing heavily from:
>
> - Date::ICal & Time::Piece
> - Date::Calc and the stuff it comes from
> - Date::Set
> - Date::Parse (good simple parsing routine)
> - Date::Manip (the code is ugly but it does very cool things)
> - Date::ICal::Timezone - in reefknot CVS
My biggest concern is duplication. When two modules do the same thing,
you split your users between them, and bugs get fixed in only one place.
Not a show-stopper, just something to be aware of.
> Modules from which there are no doubt good bits of code to steal, plus
> inspiration for various features
>
> - Class::Date
> - Date::Handler
> - Date::Convert
> - others, no doubt
Many many others.
> And here's a set of goals:
>
> 1. Produce the above-mentioned modules, starting with DateTime::Object,
> the base class. The most important thing here is to come up with an API,
> and a functional first implementation. Where possible, use existing code
> in new modules. Where that's impractical (Date::Calc), simply use the
> other module under the hood, and provide an API to it that fits into the
> rest of the scheme.
I'm particularly in favor of this latter approach. Especially getting
going. It somewhat smacks of screen-scraping, but it lets us get going
fast, and work with existing module authors who don't want a radical
conversion, but want to at least cooperate with the program.
> Especially steal test suites from as many modules as possible!
Yes. Test suites. Lots of them!
> 2. Integrate everything into our datetime module suite codebase. This
> means that where things are being used under the hood, we re-implement as
> needed.
>
> 3. Now we have stuff that works. Good. At this point we focus on several
> separate goals. Optimizing the base pieces. For example, I'm sure a lot
> of the base date object and date math can be implemented in C. Same for
> date calculations (see Date::Calc).
>
> Work on complex bits like fancy date parsing (Date::Manip), datetime span
> sets.
>
> So, who's ready to chew ass and kick some bubble-gum?!
Count me in. I have many fewer tuits than I once had, but this sounds
really awesome. At the least, I can participate in discussion.
Hmm. This might actually give me a reason to try to make it to YAPC this
year. Darn you. When things seemed so simple ...
--
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)
Thread Previous
|
Thread Next