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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/guido%40python.org >>> >>> >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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