[Python-Dev] Epoch and Platform

Curt Hagenlocher curt at hagenlocher.org
Tue Jun 17 01:08:53 CEST 2008


The documentation for the time module says that "the epoch is the point
where the time starts. On January 1st of that year, at 0 hours, the ``time
since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the
epoch is, look at gmtime(0)."  This confirms that the epoch is
platform-specific.  As such, the only legal uses of the timestamp should be

1) comparing with another timestamp to determine elapsed time in seconds
2) passing to another standard Python library function which expects a
timestamp
3) as a source of randomness.

However, the following files in the standard library have hardcoded the
assumption that the Python epoch will always be the same as the Unix epoch:
In gzip.py, method GzipFile._write_gzip_header
In tarfile.py, method _Stream._init_write_gz
In uuid.py, function uuid1

Additionally, the following files in the standard library have hardcoded the
assumption that the Python epoch will cause timestamps to fall within the
range of a 32-bit unsigned integer value:
In imputil.py, function _compile
In py_compile.py, function compile

So there's some kind of a potential discrepancy here, albeit a minor one.
This discrepancy can be resolved in one of at least three ways:

1) The documentation for the time module is wrong, and the epoch for Python
(at least versions 2.x) should be the Unix epoch.
2) These library functions are slightly wrong and should be modified by
subtracing an "epoch offset" before doing other calculations. This offset
can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) -
time.timezone".
3) These library files should be considered part of the platform-specific
implementation, and an alternate platform should provide its own version of
these files if necessary.

Any thoughts on this?

>From the perspective of implementing IronPython, I'd prefer that the answer
is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as
possible, while respecting CLR-specific norms for functionality which is
left up to individual implementations.

--
Curt Hagenlocher
curt at hagenlocher.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080616/2e763e34/attachment-0001.htm>


More information about the Python-Dev mailing list