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

Guido van Rossum guido at python.org
Tue Jun 17 19:56:13 CEST 2008

On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher <curt at hagenlocher.org> wrote:

I don't feel anxious, but my doctor has been trying to persuade me to switch to decaf...

There's no real urgency. The reason this came up is because I just implemented zlib, which automatically enabled the gzip unit tests. The gzip tests are failing because the current timestamp can't be written as a 32-bit value.

Why is that? Is it because your epoch is different? If so, I would much prefer the epoch to be 1970. (Maybe this is the resolution you're seeking?)

In order to checkin my changes, I can't have any failing tests -- so my choices are

1) change the IronPython epoch so that the timestamp works for gzip and tarlib 2) change gzip and tarlib to work with a "less standard" epoch, or 3) disable the failing test(s) ...and I'd rather not resort to #3, if possible. On Tue, Jun 17, 2008 at 10:03 AM, Guido van Rossum <guido at python.org> wrote: Can you explain why you are so anxious to get this resolved (apart from the beer :-) ?

On Tue, Jun 17, 2008 at 9:26 AM, Curt Hagenlocher <curt at hagenlocher.org> wrote: Any chance of an Official Pronouncement on this topic? It would help us greatly -- even if only to figure out who'll be paying for the next round of beer.

On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum <guido at python.org> 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

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list