Guido van Rossum wrote:
Maybe we need yet another datetime type that measures "wall clock time"???
Gosh, time computations are full of surprises, even of you disregard the Julian calendar and leap seconds. :-(
It's good to hear you say that. Your opinion earlier -- which I wanted to agree with, but couldn't see how -- seemed to be "This is so *EASY*, why can't anybody just get it done the way I want??!" :) Elsewhere, Guido van Rossum wrote:
I'm very tempted to put all the smarts in conversions though: you can take a naive datetime object, interpret it in a particular timezone using a given DST ruleset (local time and UTC being two common cases) and convert it to a timestamp, which has different semantics, but can be converted back to naive time by interpreting according to some timezone.
Okay: Dumb objects, smart conversions. I like this a lot. If the conversions are even minimally flexible, better timezone support can be added later. Maybe even calendars. timestamp <---timezone/calendar-aware conversion---> datetime (no TZ or DST) (broken-down; with TZ; maybe not DST) Casual users would only ever see (or care about) the datetime type and its year/month/day/etc. fields. By default, the broken-down time is determined using localtime(). Sometimes timestamps are appropriate, sometimes datetimes. They serve different programming goals. Both are small in terms of storage; each supports a different sort of arithmetic. Both have fast __cmp__ operations. For simplicity, the timestamp type could just be "float" (the type returned by time.time()). Or it could be something nicer that has (naively) broken-down fields of its own. I've got pseudocode if anyone is interested. :| ## Jason Orendorff http://www.jorendorff.com/