[Python-ideas] Reduce platform dependence of date and time related functions

random832 at fastmail.us random832 at fastmail.us
Wed Sep 18 19:20:43 CEST 2013


On Wed, Sep 18, 2013, at 9:34, M.-A. Lemburg wrote:
> Right, but those APIs are all limited to what the platforms
> defines as t_time and like you say: those values are often
> limited to certain ranges.

We're going around in circles. I'm proposing _removing_ those
limitations, so that for example code written for Unix systems (that
assumes it can use negative values before 1970) will work on Windows,
and code written for 64-bit systems will work on systems whose native
time_t is 32 bits.

It occurs to me that you might have misunderstood me. By "APIs" I was
not referring to the platform functions themselves (which, obviously,
are limited to what the platform's type can represent, and sometimes
impose arbitrary limits on top of that), I was talking about
datetime.fromtimestamp, the various functions in the time module,
calendar.timegm, os.stat, and so on. There's no reason _those_ should be
limited to what the platform defines.

Just because "seconds since 1970" was invented by a platform does not
mean it should be considered to be a platform-dependent representation.
There's nothing _wrong_ with it as a representation of UTC, except for
the fact that it can't represent leap seconds, and I suspect a lot of
other things break in the presence of leap seconds anyway. The fact that
timedelta is defined as a days/seconds combination, for example. In the
presence of leap seconds, it shouldn't be possible to normalize them any
more than if there were a months or years field.

> If you want platform independent representations, use one of the
> available conversion routines to turn the time_t values into
> e.g. datetime objects and ideally convert the values to UTC
> to avoid time zone issues. Then use those objects for date/time
> calculations.
> 
> time_t values are really not a good basis for doing date/time
> calculations. Ideally, they should only be used and regarded
> as containers holding a platform dependent date/time value,
> nothing more.

That ship sailed long ago. This isn't a Python 4000 thread; we're
talking about the API we have, not the one we want.


More information about the Python-ideas mailing list