> [Guido] > > Yes. A "day" is always 24 hours. [Tim] > In real life, if it's 3pm on the day before DST begins or ends, and > I count off 24 hours, "one one thousand, two one thousand, three one > thousand, ... eighty six thousand four hundred one thousand", I'm > going to look up and see 2pm or 4pm on my high-tech auto-adjusting > clocks. If I add 24 hours to my datetime object, though, I'm going > to see 3pm. > > The only conclusion I have at this time is that I like datetime > objects better than real life <wink>. 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! 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"??? Gosh, time computations are full of surprises, even of you disregard the Julian calendar and leap seconds. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4