Aahz Maruch wrote:
Fredrik Lundh wrote: >
Or to put it another way, I want the following to work for any time object, including mxDateTime objects, any date/timestamp returned by a DB-API driver, and weird date/time-like types I've developed myself:
if isinstance(t, basetime): # yay! it's a timestamp print t.timetuple()
Looks good! I'd prefer None to -1, though, for the last three items of the tuple.
None would be better from an interface design POV, but for historic reasons (compatibility to localtime()) -1 is better.
Also, the raise on utctime() should be NotImplementedError, maybe?
In the DB API we let the implementors decide: if the functionality cannot be provided per design, then it should not be implemented; if it can be implemented, but only works under certain conditions, a DB API NotSupportedError is raised instead.
For mxDateTime I would implement both methods since mxDateTime does not store a timezone with the value but instead defines methods (and other operations) based on assumptions about the value. Time zones are on the plate, though, and the parser already knows about them.
The C lib only provides APIs for local time and UTC; if you ever tried to convert a non-local time value into UTC, you'll know that this is not easy at all (mostly because of the troubles caused by DST and sometimes also due to leap seconds getting in the way).
About the proposed interface:
I'd rename the type to datetimebase and the methods to .tuple() and .gmtuple().
y,m,d = datetime.tuple()[:3] h,m,s = datetime.utctuple()[3:6]
IMHO, it looks better :-)
One thing I'm missing is a definition for a constructor (type objects are callable, so it'll have to do something, I guess...) and there should also be a datetimedeltabase type (this one is needed for dealing with the difference between two datetime values).
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH