[Python-Dev] Interop between datetime and mxDateTime
Tim Peters
tim.one@comcast.net
Tue, 14 Jan 2003 14:59:52 -0500
[Guido]
> ...
> - The range of datetime (1 <= year <= 9999) is much larger than the
> range of ticks (1970 <= year < 1938). I suppose it could raise an
> exception when the time is not representable as ticks.
The range of ticks is platform-dependent, if you want to use C library
functions that accept ticks. The small range you're thinking of is due to
platforms using 32-bit ints to represent ticks. A float has ("almost always
has") 53 bits of precision, so as long as the timestamp isn't fed into
platform C routines there's no problem expressing the whole range of dates
datetime supports (to 1-second resolution, that only requires about 38 bits;
so we wouldn't have a problem with the whole range even to millisecond
resolution).
> - A C double doesn't have enough precision for roundtrip guarantees.
That part is so -- it would require a little more than 58 bits to roundtrip
microseconds too correctly.
There's another glitch: MAL plays tricks trying to accomodate boxes set up
to support leap seconds. datetime does not, and on such a box there exist
timestamps t1 and t2 such that t1 - t2 == 1 but where
datetime.fromtimestamp(t1) == datetime.fromtimestamp(t2). The reason is
that fromtimestamp() uses the platform localtime() or gmtime() to convert
the timestamp to a struct tm, and then ruthlessly clamps tm_sec to be no
larger than 59 (on boxes supporting leap seconds, the current standards
allow for tm_sec to be 60 too, and older standards also allowed for tm_sec
to be 61; if datetime sees one of those, it knocks it down to 59).
datetime's fromtimestamp() should probably be reworked not to use the
platform localtime()/gmtime(), implementing a "pure" POSIX timestamp
regardless of platform delusions. OTOH, timestamps have no value in
datetime now except as a legacy gimmick.
> - Does it really need to be automatic? I.e., does it really need to
> be __float__()? I'd be less against this if it was an explicit
> method, e.g. dt.asposixtime().
Me too. totimestamp() would make most sense for a name (given existing
methods like toordinal(), fromordinal(), and fromtimestamp()).