Guido van Rossum wrote: > > > [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! You should forget about DST if you want a sane implementation. Same for leap seconds. > 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"??? You should be very careful not to make all of this too confusing by trying to put everything into one bag. If someone wants DST and timezone aware time differences, then this is a completely different concept than taking the difference w/r to number of days. Just to hint at another problem: you sometimes want to know the time difference of two dates in terms of years, months, days, hours, etc. that is, you are not interested in 86400 second days, but in calendar days or even months. For months you'll run into problems with non-existing days, e.g. for 2002-03-31 - 1 month. > Gosh, time computations are full of surprises, even of you disregard > the Julian calendar and leap seconds. :-( Hehe, I had the same impression when I started with mxDateTime. At first, it seemed like a simple write up, but once I got into the details, things started to become very confusing. In my implementation, I decided to use mathematical model for the representation and to leave most of the complex stuff to interface methods. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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