[Python-Dev] Epoch and Platform (original) (raw)

Forest list8a.forest at tibit.com
Tue Jun 17 19:21:39 CEST 2008

ISTR using a Microsoft C compiler in the early/mid 1990s whose runtime library used an unusual epoch. I don't recall any others straying from the Unix way, but then again, I haven't been looking for such quirks.

Guido wrote:

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 runtime. 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 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.writegzipheader In tarfile.py, method Stream.initwritegz 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 pycompile.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

More information about the Python-Dev mailing list