[Python-Dev] Interop between datetime and mxDateTime (original) (raw)

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()).