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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4