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

Re: Picking up the ball

Thread Previous | Thread Next
Dave Rolsky
January 10, 2003 10:27
Re: Picking up the ball
Message ID:
On Fri, 10 Jan 2003, Rich Bowen 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 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.

This has been brewing in my head since the summer, when I worked on a
project that involved providing simple calendaring functions as part of a
web app, and I realized how annoying it was that there was no datetime
standard for Perl.

> > 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.

I think we can stick with the julian days and seconds used in Date::ICal
for now, with the addition of fractional seconds.  Again, with a good,
_well-defined_ API, someone can come along and create a different
implementation of the same API.

> > Rich says he gave up trying to herd the cats -
> >
> Also, some of the cats very adamantly stated that they had no interest
> in being herded - that they *liked* being free-range cats.

Like I said, screw them.  If they don't want to play we use what we like
of their code.  If this project is successful, their modules will be used
less and less anyway.  It seems like a lot of people think this project is
a good idea, so I see no reason to let it be stopped just because a few
authors of existing modules don't buy into it.

> Jesse is one of our great storehouses of good ideas and positive karma.
> Yay Jesse. <subliminal>Everyone needs to use RT</subliminal>

RT is good.  I've used it for several projects so far.

> 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.

Yeah, Time::HiRes stays where it is, primarily because it overrides
CORE::time ;)

In fact, I don't care if anything _moves_ or not.  If there's
functionality that belongs in the new datetime suite, then we first ask
the module author to rename and rewrite to conform to the standard.  If
they refuse, we rewrite and repackage ;)

> 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.

It looks like most people prefer DateTime, which I've actually warmed up
to myself.

> 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.

Well, considering Date::ICal uses julian days and seconds internally, it
seems like ical is just another input/output format.  It's one we should
support, especially given how trivially easy that is to do.

> > -- 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.

My plan was to take the Date::ICal _code_ and use it as the beginning of
the module.  If there's still a need for a Date::ICal module,
in that particular namespace, then it can be a thin wrapper around

> > -- 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.

A very good point.  Kind of like the Perl regex engine.

> <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.

More recruiting to be done, then ;)

> > -- 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*

Hmm, good points.  I think there's some _common_ calculations that are
probably worth having all together.  For example, calculating what week of
the year a date falls in, when the first full week of the year starts,
etc.  But on looking at Date::Calc more, it looks like much of what it
provides will be part of the base date object anyway.

I'm not _too_ worried about this aspect.  Once the base parts of
implemented, if there's more stuff that needs doing, we can deal with it

> > - 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.

Looks interesting.  I'm sure there's some code that we can steal in there.

> > -- 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.

The implementation of each piece may be hard, but the important thing is
to make it flexible.  I want to be able to say:

  use DateTime;

  # under the hood will load DateTime::Calendar::USAHoliday &
  # DateTime::Calendar::IslamicHoliday
  my $date = DateTime->new( epoch => time,
                            calendars => [ qw( USAHoliday IslamicHoliday ) ] );

  # consults its two calendar objects for the first mutually agreed upon
  # business day.
  my $next = $date->next_business_day;

> > - 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?

It's archived at, though
I don't see any of the recent messages there.

Aha, found one:

I'm going to ask the MARC folks to add this list, I think.  I like their
search engine.

> > -- 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?

Exactly.  Date::Manip already does this, but there's two big problems with

1. The code is a huge, slow, monolithic hog.
2. The internals are ick.

That's why I say a _refactored_ Date::Manip.  I want to preserve the
algorithms and regexes, but without a lot of the other baggage it has.

> > - 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?

It doesn't have to be in our class, but it must conform to the defined

> > - 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.

Well, recurring meetings are a perfect example.  If you meet every Tuesday
from 7PM-9PM, that's an infinitely recurring set of datetime spans.

> > -- 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.

I don't think it's crucial in the sense of "nobody will use this stuff
without this feature".  It's cool, but definitely lower down on the list.

> > - DateTime::Algorithm - aka Rich's proposed Date::Algorithm.  Includes
> > things like:
> >
> > -- DateTime::Algorithm::Leapyear
> > -- DateTime::Algorithm::Passover
> Isn't that DateTime::Event::Passover?

Doh, I'm confusing myself.  I think maybe DateTime::Algorithm and
DateTime::Event have _way_ too much overlap.

I also realized that some set of algorithms will probably be common enough
that they should be lumped together in a single
"DateTime::Algorithm::Library" module.

> > - 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.

Whether lots of other people use them or not, it's still a good thing to
work them into the standard.

> > - 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.

Or the Event namespace.  There are things that might go in algorithm that
aren't events, but not vice versa, I think.

> I've got dibs on the FourthofJuly one, though. ;-)

It's all yours ;)

I'll claim DateTime::Event::NewYearsDay ;)

> > 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.

I really, really, really hope that if this project becomes successful,
that most of the above-mentioned modules become basically obsolete.

> Hmm. This might actually give me a reason to try to make it to YAPC this
> year. Darn you. When things seemed so simple ...

I'll probably be there, despite the fact that I really don't want to go to


House Absolute Consulting

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