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