<div>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</div>
<div> </div>
<div>1) comparing with another timestamp to determine elapsed time in seconds</div>
<div>2) passing to another standard Python library function which expects a timestamp</div>
<div>3) as a source of randomness.</div>
<div> </div>
<div>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:</div>
<div>In gzip.py, method GzipFile._write_gzip_header</div>
<div>In tarfile.py, method _Stream._init_write_gz</div>
<div>In uuid.py, function uuid1</div>
<div> </div>
<div>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:</div>
<div>In imputil.py, function _compile</div>
<div>In py_compile.py, function compile</div>
<div> </div>
<div>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:</div>
<div> </div>
<div>1) The documentation for the time module is wrong, and the epoch for Python (at least versions 2.x) should be the Unix epoch.</div>
<div>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".</div>
<div>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.</div>
<div> </div>
<div>Any thoughts on this?</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>--</div>
<div>Curt Hagenlocher</div>
<div><a href="mailto:curt@hagenlocher.org">curt@hagenlocher.org</a></div>