[Python-Dev] dateutil

[Brett C.]

Responding to both Tim's and Gustavo's follow-ups to my email here.


Tim Peters wrote:

> [Brett C.]
> 
>>Before I give my vote on DateUtil I know I would love to hear Gustavo
>>give a quick comparison to datetime in terms of what DateUtil provides
>>over datetime.
<SNIP>
> 
> WRT time deltas, datetime stuck to things people can't reasonably argue
> about, while DateUtil (like mxDateTime before it) is in the business of
> guessing what people really want.  That's why, e.g., datetime.timedelta has
> no months= argument.  People can (and do) argue about what "a month" means
> (what's one month after January 31?  A few days into March?  The last day of
> February?  4 weeks later?  30.436875 days later (that's 365.2425/12 == the
> average length of a year in days divided by 12)?).  They can't argue about
> what "a week" means -- it's 7 days.  And a day is 24 hours, and an hour is
> 60 minutes, and a minute is 60 seconds, and a second is 10000000
> microseconds, and "leap seconds" don't exist.
> 
> Ya, that was a gutless decision, but it also means datetime isn't about to
> change the rules on you because some other notion of "month" becomes
> fashionable.  datetime is about naive time, an idealized calendar and an
> idealized clock that won't change even if social or legislative or physical
> reality does.  It's a safe fantasy land where you can block out the world's
> noise.  That's also why it ignores timezones <wink>.
> 

This all makes sense to me.  No need to try to pigeonhole others into 
our own definitions of date/time "stuff".

> 
>>The rrule idea does sound cool and could be neat to add to datetime.
>>I can see having an iterator for these things being useful to someone
>>(unless I am making myself partially look like a fool again by having
>>this be in datetime already without me realizing it).
> 
> 
> Nope, they're not, and things like "the second Tuesday of the month" aren't
> supported natively by datetime at all.  They're easy enough to compute using
> datetime as a basis, but the datetime Wiki was full of incompatible
> suggestions about what people really wanted there.  We didn't have time (or
> interest) in settling those arguments, so we covered our asses by leaving it
> out.  Gustavo is covering his by appealing to an external standard, which is
> an admirable strategy.
> 

OK, so this does sound cool.  I wouldn't mind seeing this added to the 
language for those values that are not questionable as with the 
timedeltas (if there even are any).



Gustavo Niemeyer wrote:
 > 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.

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

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

 > * Generic parsing of dates in almost any string format;
 >

Seems like a convenience wrapper around strptime .  Personally I would 
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.  =)

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

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



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.

-Brett