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

[Guido van Rossum]

> 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.

Yesterday I finally realized what the tm_isdst flag is really for.
It's so that you can represent any UTC timepoint as local time,
without ambiguity.  The only time when the DST flag is needed is in
the one hour per year where DST and non-DST overlap: the first hour
after the clock is set back an hour (at the end of the summer).

> 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
> ...

...Or something like that.  I'm beginning to agree that our treatment
of timezones is not right.  See my next message.

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

:-)

> 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>.

No thanks.  I'd rather reimplement HTTP 1.1 from scratch...

--Guido van Rossum (home page: http://www.python.org/~guido/)