> On 15 Apr 2021, at 14:48, Antoine Pitrou wrote:
>
> On Thu, 15 Apr 2021 14:32:05 +0200
> Victor Stinner wrote:
>> SOURCE_DATE_EPOCH is not a random variable, but is a *standardised*
>> environment variable:
>> https://reproducible-builds.org/docs/source-date-epoch/
>
> Standardized by whom?
On Thu, 15 Apr 2021 14:32:05 +0200
Victor Stinner wrote:
> SOURCE_DATE_EPOCH is not a random variable, but is a *standardised*
> environment variable:
> https://reproducible-builds.org/docs/source-date-epoch/
Standardized by whom? This is not a POSIX nor Windows standard at
least. Just because a
SOURCE_DATE_EPOCH is not a random variable, but is a *standardised*
environment variable:
https://reproducible-builds.org/docs/source-date-epoch/
This page explains the rationale. See the “Lying about the time” /
“violates language spec” section ;-)
More and more projects adopted it. As I wrote,
On Thu, 15 Apr 2021 11:28:03 +0200
Victor Stinner wrote:
> If gzip is modified to use SOURCE_DATE_EPOCH timestamp, you get a
> reproducible binary and you don't need to add a new constant ;-)
> SOURCE_DATE_EPOCH is a timestamp: number of seconds since Unix Epoch
> (January 1, 1970 at 00:00).
Chan
If gzip is modified to use SOURCE_DATE_EPOCH timestamp, you get a
reproducible binary and you don't need to add a new constant ;-)
SOURCE_DATE_EPOCH is a timestamp: number of seconds since Unix Epoch
(January 1, 1970 at 00:00).
Victor
On Wed, Apr 14, 2021 at 8:15 PM wrote:
>
> The gzip specific
On 4/14/2021 8:00 AM, Joachim Wuttke wrote:
Furthermore, if policy about API changes allows, I'd suggest
that `NO_TIMESTAMP` become the new default value for `mtime`.
Changing defaults is a huge pain, which we mostly avoid.
--
Terry Jan Reedy
___
On Wed, 14 Apr 2021 21:38:11 +0100
Steve Holden wrote:
> DEFAULT_TIMESTAMP?
It's not a default timestamp, it's a placeholder value meaning "no
timestamp". The aforementioned RFC 1952 explicitly says: "MTIME = 0
means no time stamp is available".
So yes, it really means "no timestamp", regardles
DEFAULT_TIMESTAMP?
Kind regards,
Steve
On Wed, Apr 14, 2021 at 8:03 PM wrote:
> If the so, then a better name than NO_TIMESTAMP should be chosen, as the
> gzip specification does not allow for no timestamp.
> ___
> Python-Dev mailing list -- python-d
If the so, then a better name than NO_TIMESTAMP should be chosen, as the gzip
specification does not allow for no timestamp.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.pyt
On Wed, 2021-04-14 at 18:06 +, j.wut...@fz-juelich.de wrote:
> The gzip specification [1] makes clear that the mtime field is always present.
> The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970.
> MTIME = 0 means no time stamp is available. Hence no need for a
> new co
The gzip specification [1] makes clear that the mtime field is always present.
The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970.
MTIME = 0 means no time stamp is available. Hence no need for a
new constant NO_TIMESTAMP.
So this is primarily a documentation problem [2]. F
Hi,
gzip.NO_TIMESTAMP sounds like a good idea. But I'm not sure about
changing the default behavior. I would prefer to leave it unchanged.
I guess that your problem is that you don't access gzip directly, but
uses a higher level API which doesn't give access to the timestamp
parameter, like the t
On Wed, Apr 14, 2021 at 5:00 AM Joachim Wuttke
wrote:
> gzip compression, using class GzipFile from gzip.py, by default
> inserts a timestamp to the compressed stream. If the optional
> argument `mtime` is absent or None, then the current time is used [1].
>
> This makes outputs non-deterministic
13 matches
Mail list logo
