[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/