[Python-Dev] dateutil

[Gustavo Niemeyer]

> > Here is a quick list of features, from the website:
> >
> > * Computing of relative deltas (next month, next year,
> >   next monday, last week of month, and a lot more);
> 
> As Tim pointed out, this is a little sticky.  I personally appreciate 
> datetime's choice of not trying to force me into a specific 
> interpretation of what a "month" is.  I say stay naive.

I appreciate it too. As Tim noticed, the idea is leaving to higher level
tools the task to decide what a month is. That's what relativedelta is,
a higher level tool. OTOH, I woulnd't include "adding a month" as the
main usage for it. I've seen more than once in python list someone
asking "hey, how do I know how long ago has D date happened, in human
style". That's the kind of task which is handled by dateutil.

> > * Computing of relative deltas between two given
> >   date and/or datetime objects;
> 
> Without the relative delta values based on the "questionable"
> date/time "stuff" this seems to boil down to datetime.timedelta .

Sorry, but I think you're undermining relativedelta's usage. timedelta
is as powerfull as adding seconds to a given epoch. That's really nice
to have in datetime, but it's not the task that relativedelta tries to
accomplish.

> > * Computing of dates based on very flexible recurrence rules
> >   (every month, every week on Thursday and Friday, every
> >   Friday 13th, and a *LOT* more), using a superset of the
> >   iCalendar RFC specification. Parsing of RFC strings is
> >   supported as well.
> 
> This is very cool.  It's based on an accepted API which is a big plus 
> and the functionality could be very useful.

Thanks!

> > * Generic parsing of dates in almost any string format;
> 
> Seems like a convenience wrapper around strptime .  Personally I would 

No, it's not a wrapper around strptime. It's a smart date parsing
mechanism. The smartest I'm aware about (I've obviously researched
before starting to write it). It will not only parse most used date
strings (no it doesn't parse english statements), but will also
interpret timezone information correctly using Python's tzinfo
notation.

Some people claim that this is "dangerous", since there are
ambiguous dates, like "03-03-03". In my opinion, this is completely
non-sense, since dateutil's parsing routine has a well defined,
documented, and simple behavior. If you're parsing US dates, the default
is ok. If you're parsing brazilian dates, pass it "dayfirst=1" and
you're done. What other ways would you parse it!? Ahh.. of course.
Perhaps you'd prefer to say "%a, %d %b %Y %H:%M:%S %z" than
"dayfirst=1", since it's a lot more obvious what you're parsing, isn't
it?  ;-)

> love for datetime objects to have a class method to be able to take in 
> the appropriate ISO-formatted date/time string and return the 
> appropriate datetime object.  Otherwise I would rather keep the 
> interface clean of string parsing short of using strptime .
> 
> But then again maybe I just don't want strptime to become obsolete.  =)

Sure.. if you prefer using an explicit format, strptime() is for you.
I'd rather use something which accepts all common formats correctly
without having to tell it what format it is. It's all about choice.

> > * Timezone (tzinfo) implementations for tzfile(5) format
> >   files (/etc/localtime, /usr/share/zoneinfo, etc), TZ
> >   environment string (in all known formats), iCalendar
> >   format files, given ranges (with help from relative deltas),
> >   local machine timezone, fixed offset timezone, and UTC
> >   timezone.
> >
> 
> This could be good.  Beyond knowing that timezones are a pain in the
> rear to deal with in terms of DST I don't know *how* good it would be.
> I know datetime stays away from timezones, but if it can be gleaned
> from the system cleanly it might be nice to have that option.  Breaks
> with the naive view that I am supporting here, but this stuff can be
> hard to deal with so I think it wouldn't hurt to have.

Everything dateutil provides is hard to deal with if you don't have
the necessary tools.

> > * Computing of Easter Sunday dates for any given year,
> >   using Western, Orthodox or Julian algorithms;
> 
> Don't really see the use in this other than the rule figuring this out 
> is odd enough that I never remember.  Who really cares when Easter is 
> beyond certain religious groups?

Other people already answered that issue.

> OK, so with the rrule stuff, I am +1 on adding those if we can come up 
> with a clean way to add them to datetime (I don't think we need a 
> separate module as Jim Jewett pointed out; we already have enough 
> date-related modules).  -1 for the timedelta stuff since I am fine with 
> not handling timedeltas for "a month from now", etc. unless we can get 
> that kind of definition from the iCalender API and thus have a 
> consistent basis on an accepted API.  And then -0 on the rest since I 
> fall in the "minimize stdlib bloat" camp.

If it'd be to include only rrule, I wouldn't like to include anything at
all. If I'll have to maintain a good part of dateutil as an extension, I
won't mind maintaining rrule as well.

-- 
Gustavo Niemeyer
http://niemeyer.net