[Python-Dev] datetime +/- scalars (int, long, float)?

[Tim Peters]

[Guido]
> Depends on how you look.  If you look at the hour attribute, or call
> the isoformat() method, or use str(), you'll see 3pm.  If you ask the
> ctime() or timetuple() methods, it converts to local time, and you'll
> see 2pm or 4pm!

I confess I never understood C's baroque timezone and DST gimmicks.  I think
I can understand the words, but they always surprised me when I tried to use
them.

>>> from datetime import datetime
>>> x = datetime(2000, 1, 1, tzoffset=60*12)
>>> print x
2000-01-01 00:00:00.000000+12:00

That's cool.  So is this:

>>> print x.utcctime()
Fri Dec 31 12:00:00 1999

The next two had me scratching my head for an hour <-0500 wink>:

>>> print x.ctime()
Fri Dec 31 07:00:00 1999
>>> print x.timetuple()
(1999, 12, 31, 7, 0, 0, 4, 365, 0)
>>>

I'm not sure the base datetime class should be in the timezone or DST
businesses at all, because there are sooooo many ways people might want to
see them done.  If we are in that business, though, I think I'd rather cut
the number of distinct methods, and have e.g. all-purpose .ctime(arg) and
.timetuple(arg) etc methods, where arg specifies whether you want to get
back the time exactly as stored, converted to UTC, or converted to local
time.  Maybe that should even be a general tzoffset-in-minute argument,
which special values outside of -1439..1439 predefined via symbolic name to
mean "as stored, UTC, or local".  Then 0 would be synonymous with "as
stored", I guess.  The natural meaning of the sign bit escapes me ...

> This deserves a caution: what starts off as a time in the local
> timezone, may end up not being the local time zone when time is added
> going across a DST transition.  Certain methods always convert to
> local time; others don't.  This can be confusing.  How can we fix
> this?  Maybe we need yet another datetime type that measures "wall
> clock time"???

If anything, the current prototype is trying to do too much, although it's a
mere fraction of what people will want.

> Gosh, time computations are full of surprises, even of you disregard
> the Julian calendar and leap seconds. :-(

I'll lend you "Calendrical Calculations".  Even *skimming* the chapters on
some of the world's other calendrical delights makes our date gimmicks blind
via the intensity of their clarity <blink>.