could someone more python-savvy than me have a look at this claim that
our SOURCE_DATE_EPOCH example for Python on
is wrong.

The claim is here:

----- Forwarded message from Brian May <b...@debian.org> -----
Date: Tue, 17 May 2016 09:16:36 +1000
From: Brian May <b...@debian.org>
To: Axel Beckert <a...@debian.org>, 824...@bugs.debian.org
Subject: Re: [Python-modules-team] Bug#824266: mkdocs: Please support   
SOURCE_DATE_EPOCH specification for build time stamps
Sender: Brian May <br...@microcomaustralia.com.au>
Organization: Debian

Axel Beckert <a...@debian.org> writes:
> See https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples
> for some examples on how to implement support for SOURCE_DATE_EPOCH,
> including an example for Python.

Response from the upstream author (please consider replying to the
upstream bug report, not here):

"FYI, the Python example is wrong. If `SOURCE_DATE_EPOCH` is supposed to
be a Unix timestamp (number of seconds since epoch), then
`time.gmtime()` is not the Python equivalent. However,
`calendar.timegm(datetime.datetime.utcnow().utctimetuple())` or
`calendar.timegm(time.gmtime())` is. It is annoyingly complicated to get
a Unix timestamp in Python. Although Python >= 3.3 makes it easier with
`datetime.datetime.utcnow().timestamp()`.  Not sure how the `datetime`
module went so long without the ability to return a timestamp."
Brian May <b...@debian.org>
----- End forwarded message -----

                Regards, Axel
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Reproducible-builds mailing list

Reply via email to