> guido wrote: > > > There was a proposal long ago that all datetime-like objects should > > implement a timetuple() method. Perhaps we should revive that? > > datetime does implement this. > > the last revision of the "time type" proposal seems to suggest that all > time types should implement the following interface: > > tm = timeobject.timetuple() This is specified in the proposal as returning local time if the timeobject knows about timezones. Unfortunately, the datetime module has timezone support built in, but in such a way that no knowledge of actual timezones is built into it. In particular, the datetime module is agnostic of the local timezone rules and regulations. We currently support timetuple() but it always returns the "naive time" represented by a datetime object (stripping the timezone info rather converting to local time). Is this a problem? If we have to convert to local time using the facilities of the time module, timetuple() will only work for dates supported by the time module (roughly 1970-2038 on most systems), and raise an error otherwise. That's not in line with datetime's philosophy (especially since there's nothing in the time tuple itself that needs such a range restriction, and other datetime types might not like this restriction either). Suggestions? > cmp(timeobject, timeobject) See Tim's post for problems with this; however if the other object derives from basetime we could return NotImplemented. > hash(timeobject) We would need to agree on how the hash should be computed in such a way that different datetime objects that compare equal hash the same. I fear this would be really hard unless we punted and made hash() return a constant. > and optionally > > deltaobject = timeobject - timeobject > floatobject = float(deltaobject) # fractional seconds > timeobject = timeobject + integerobject > timeobject = timeobject + floatobject > timeobject = timeobject + deltaobject The first and last one are already implemented for heterogeneous operations, and can be implemented by a third party datetime type; I would be against conversions between ints or floats and datetime.timedelta, because these don't roundtrip (float doesn't have enough precision to represent the full range with mucroseconds). > more here: > > http://effbot.org/zone/idea-time-type.htm The proposal also recomments an abstract base type, "basetime", for all time types. Without this, cmp() is hard to do (see Tim's post for explanation; we don't want datetime objects to be comparable to objects with arbitrary other types, because the default comparison iss meaningless). This could be a pure "marker" type, like "basestring". Marc-Andre, if we export basetime from the core, can mxDateTime subclass from that? --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