[Python-Dev] datetime +/- scalars (int, long, float)?
Jason Orendorff
jason@jorendorff.com
Thu, 7 Mar 2002 00:07:33 -0600
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/