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 <[EMAIL PROTECTED]> > 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._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 >> [EMAIL PROTECTED] _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
