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.
> 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(a)hagenlocher.org>
>> 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
>> since the epoch'' is zero. For Unix, the epoch is 1970. To find out what
>> epoch is, look at gmtime(0)." This confirms that the epoch is
>> platform-specific. As such, the only legal uses of the timestamp should
>> 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
>> 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
>> assumption that the Python epoch will cause timestamps to fall within
>> 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
>> 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
>> (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
>> 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
>> implementation, and an alternate platform should provide its own version
>> these files if necessary.
>> Any thoughts on this?
>> From the perspective of implementing IronPython, I'd prefer that the
>> is 1 or 2 -- but mainly I just want to be as compatible with "the spec"
>> possible, while respecting CLR-specific norms for functionality which is
>> left up to individual implementations.
>> Curt Hagenlocher