[Python-Dev] dateutil (original) (raw)

Brett C. bac at OCF.Berkeley.EDU
Fri Mar 12 03:29:12 EST 2004

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

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:

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.

Without the relative delta values based on the "questionable" date/time "stuff" this seems to boil down to datetime.timedelta .

This is very cool. It's based on an accepted API which is a big plus and the functionality could be very useful.

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

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.

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

More information about the Python-Dev mailing list