[Python-Dev] Epoch and Platform
Guido van Rossum
guido at python.org
Tue Jun 17 01:38:46 CEST 2008
ISTR that we force the epoch to be 1970 on all major platforms -- or
perhaps it happens to be 1970 even on Windows when using MS's C
On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <curt at hagenlocher.org> wrote:
> 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
> 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)) -
> 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
> Python-Dev mailing list
> Python-Dev at python.org
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev