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