On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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/) >> > -- --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
