[Python-Dev] Epoch and Platform

[Guido van Rossum]

On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher <curt at hagenlocher.org> 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 <guido at python.org> 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 <curt at hagenlocher.org> 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 <guido at python.org> 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 <curt at hagenlocher.org> 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
>>>>> curt at hagenlocher.org
>>>>> _______________________________________________
>>>>> Python-Dev mailing list
>>>>> Python-Dev at 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/)