SOURCE_DATE_EPOCH
SOURCE_DATE_EPOCH
is a standardised environment
variable that
distributions can set centrally and have build tools consume this in order
to produce reproducible output. In practice, SOURCE_DATE_EPOCH
specifies
the last modification of something, usually the source code, measured in the
number seconds since the Unix epoch, ie. January 1st 1970, 00:00:00 UTC
.
Before added support to a tool for reading this variable, you should scan through Debian’s checklist to see if you can avoid implementing it: a number of tools already will do this for you. However, if you find that it’s ideal for your use-case, please feel free to jump straight to our published specification.
Reading the variable
Python >= 3.x
import os
import time
import datetime
build_date = datetime.datetime.fromtimestamp(
int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
tz=datetime.timezone.utc,
)
… or with fewer imports and rendering to a string:
import os
import time
date_str = time.strftime(
"%Y-%m-%d",
time.gmtime(int(os.environ.get('SOURCE_DATE_EPOCH', time.time())))
)
for zip files:
import os
import time
import zipfile
filetime = max(315532800, int(os.environ.get('SOURCE_DATE_EPOCH', time.time())))
with zipfile.ZipFile("test.zip", 'w') as ziparchive:
file_zipinfo = zipfile.ZipInfo("hello.txt", date_time=time.gmtime(filetime))
ziparchive.writestr(file_zipinfo, "Hello world\n")
Python >= 2.x
If you still require Python 2.x support, you will need to use the
non-recommended
datetime.utcfromtimestamp
method (more info):
import os
import time
import datetime
build_date = datetime.datetime.utcfromtimestamp(
int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
)
Bash / POSIX shell
For GNU systems:
BUILD_DATE="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" +%Y-%m-%d)"
If you need to support BSD date as well you should fallback to trying ther
-r seconds
timestamp variant:
DATE_FMT="+%Y-%m-%d"
SOURCE_DATE_EPOCH="${SOURCE_DATE_EPOCH:-$(date +%s)}"
BUILD_DATE=$(date -u -d "@$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u -r "$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u "$DATE_FMT")
Perl
use POSIX qw(strftime);
my $date = strftime("%Y-%m-%d", gmtime($ENV{SOURCE_DATE_EPOCH} || time));
Makefile
DATE_FMT = +%Y-%m-%d
ifdef SOURCE_DATE_EPOCH
BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u "$(DATE_FMT)")
else
BUILD_DATE ?= $(shell date "$(DATE_FMT)")
endif
The above will work with either GNU or BSD date, and fallback to ignore
SOURCE_DATE_EPOCH
if both fails.
CMake
STRING(TIMESTAMP BUILD_DATE "%Y-%m-%d" UTC)
… will compile with CMake versions 2.8.11 and higher (released May
2013), but it only
respects SOURCE_DATE_EPOCH
since version 3.8.0 (April
2017).
Note that the final argument UTC
is required or the timestamp may vary
between timezones.
If you would like to support legacy/archival versions of CMake, you can use this less-preferred variant:
if (DEFINED ENV{SOURCE_DATE_EPOCH})
execute_process(
COMMAND "date" "-u" "-d" "@$ENV{SOURCE_DATE_EPOCH}" "+%Y-%m-%d"
OUTPUT_VARIABLE BUILD_DATE
OUTPUT_STRIP_TRAILING_WHITESPACE)
else ()
execute_process(
COMMAND "date" "+%Y-%m-%d"
OUTPUT_VARIABLE BUILD_DATE
OUTPUT_STRIP_TRAILING_WHITESPACE)
endif ()
Note that the above will work only with GNU date
; see the POSIX shell
example on how to support BSD date.
Meson
By deliberate design, Meson does not provide access to environment
variables in build
files
which makes accessing SOURCE_DATE_EPOCH
troublesome.
date_exe = find_program('date')
cmd = run_command('sh', '-c', 'echo $SOURCE_DATE_EPOCH')
source_date_epoch = cmd.stdout().strip()
if source_date_epoch == ''
source_date_epoch = run_command(date_exe, '+%s').stdout().strip()
endif
formatted_date = run_command(date_exe, '-u', '-d', '@' + source_date_epoch, '+%Y-%m-%d').stdout().strip()
The above will work only with GNU date
. See the POSIX shell example on how
to support BSD date variants.
Dockerfile
The SOURCE_DATE_EPOCH
argument value is automaticallly propagated from the
SOURCE_DATE_EPOCH
environment value of the client host, since Docker
Buildx v0.10.
The SOURCE_DATE_EPOCH
argument value can be captured as an environment
value for RUN
instructions, by putting an ARG
instruction between FROM
and RUN
:
FROM [...]
ARG SOURCE_DATE_EPOCH
RUN [...]
Capturing the SOURCE_DATE_EPOCH
argument value is optional.
Alternatively, the SOURCE_DATE_EPOCH
environment value can be declared
inside a RUN
instruction too.
FROM [...]
ADD src /src
RUN [...]
SOURCE_DATE_EPOCH="$(find /src -type f -exec stat -c '%Y' {} + | sort -nr | head -n1)"; \
export SOURCE_DATE_EPOCH; \
# for logging validation/edification
date --date "@$SOURCE_DATE_EPOCH" --rfc-2822; \
[...]
Scope
Regardless to whether the SOURCE_DATE_EPOCH
argument value is captured
into Dockerfile with ARG SOURCE_DATE_EPOCH
, the argument value is also
used for: - the created
timestamp in the OCI Image
Config
- the
created
timestamp in thehistory
objects in the OCI Image Config - the
org.opencontainers.image.created
annotation in the OCI Image Index - the timestamp of the files exported with the
local
exporter - the timestamp of the files exported with thetar
exporter
To apply the SOURCE_DATE_EPOCH
argument value to the timestamps of the
files inside the image, specify rewrite-timestamp=true
as an image
exporter option:
docker buildx create --use --name buildkit
docker buildx build --output type=image,name=docker.io/username/image,push=true,rewrite-timestamp=true .
The rewrite-timestamp
option is not set to true
by default due to the
overhead of rewriting image layers.
apt-get
RUN apt-get
does not automatically consume SOURCE_DATE_EPOCH
to install
packages from the past snapshot.
https://github.com/reproducible-containers/repro-sources-list.sh can be used for reconfiguring /etc/apt/sources.list
to use https://snapshot.debian.org/archive/debian/<SOURCE_DATE_EPOCH>/
.
Further information
See: - https://github.com/moby/buildkit/blob/master/docs/build-repro.md - https://github.com/docker-library/official-images/issues/16044
C
#include <errno.h>
#include <limits.h>
#include <stdlib.h>
struct tm *build_time;
time_t now;
char *source_date_epoch;
unsigned long long epoch;
char *endptr;
source_date_epoch = getenv("SOURCE_DATE_EPOCH");
if (source_date_epoch) {
errno = 0;
epoch = strtoull(source_date_epoch, &endptr, 10);
if ((errno == ERANGE && (epoch == ULLONG_MAX || epoch == 0))
|| (errno != 0 && epoch == 0)) {
fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: strtoull: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
if (endptr == source_date_epoch) {
fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: No digits were found: %s\n", endptr);
exit(EXIT_FAILURE);
}
if (*endptr != '\0') {
fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: Trailing garbage: %s\n", endptr);
exit(EXIT_FAILURE);
}
if (epoch > ULONG_MAX) {
fprintf(stderr, "Environment variable $SOURCE_DATE_EPOCH: value must be smaller than or equal to %lu but was found to be: %llu \n", ULONG_MAX, epoch);
exit(EXIT_FAILURE);
}
now = epoch;
} else {
now = time(NULL);
}
build_time = gmtime(&now);
If you want less verbose code and are happy with the assumptions stated below, you can use
#include <stdlib.h>
time_t now;
char *source_date_epoch;
/* This assumes that the SOURCE_DATE_EPOCH environment variable will contain
a correct, positive integer in the time_t range */
if ((source_date_epoch = getenv("SOURCE_DATE_EPOCH")) == NULL ||
(now = (time_t)strtoll(source_date_epoch, NULL, 10)) <= 0)
time(&now);
C++
#include <sstream>
#include <iostream>
#include <cstdlib>
#include <ctime>
time_t now;
char *source_date_epoch = std::getenv("SOURCE_DATE_EPOCH");
if (source_date_epoch) {
std::istringstream iss(source_date_epoch);
iss >> now;
if (iss.fail() || !iss.eof()) {
std::cerr << "Error: Cannot parse SOURCE_DATE_EPOCH as integer\n";
exit(27);
}
} else {
now = std::time(NULL);
}
Go
import (
"fmt"
"os"
"strconv"
"time"
)
[...]
source_date_epoch := os.Getenv("SOURCE_DATE_EPOCH")
var build_date string
if source_date_epoch == "" {
build_date = time.Now().UTC().Format(http.TimeFormat)
} else {
sde, err := strconv.ParseInt(source_date_epoch, 10, 64)
if err != nil {
panic(fmt.Sprintf("Invalid SOURCE_DATE_EPOCH: %s", err))
}
build_date = time.Unix(sde, 0).UTC().Format(http.TimeFormat)
}
PHP
\date('Y', (int)\getenv('SOURCE_DATE_EPOCH') ?: \time())
Emacs-Lisp
(current-time-string
(when (getenv "SOURCE_DATE_EPOCH")
(seconds-to-time
(string-to-number
(getenv "SOURCE_DATE_EPOCH"))))))
OCaml
let build_date =
try
float_of_string (Sys.getenv "SOURCE_DATE_EPOCH")
with
Not_found -> Unix.time ()
Java / gradle
def buildDate = System.getenv("SOURCE_DATE_EPOCH") == null ?
new java.util.Date() :
new java.util.Date(1000 * Long.parseLong(System.getenv("SOURCE_DATE_EPOCH")))
Javascript / node.js
var timestamp = new Date(process.env.SOURCE_DATE_EPOCH ? (process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime());
// Alternatively, to ensure a fixed timezone:
var now = new Date();
if (process.env.SOURCE_DATE_EPOCH) {
now = new Date((process.env.SOURCE_DATE_EPOCH * 1000) + (now.getTimezoneOffset() * 60000));
}
Coffeescript
now = new Date()
if process.env.SOURCE_DATE_EPOCH
now = new Date((process.env.SOURCE_DATE_EPOCH * 1000) + (now.getTimezoneOffset() * 60000))
Ruby
if ENV['SOURCE_DATE_EPOCH'].nil?
now = Time.now
else
now = Time.at(ENV['SOURCE_DATE_EPOCH'].to_i).gmtime
end
Note that Ruby’s Datetime.strftime is locale-independent by default.
Scala
To get milliseconds since Epoch:
sys.env.get("SOURCE_DATE_EPOCH").map(_.toLong * 1000)
To get a java.util.Date
:
sys.env.get("SOURCE_DATE_EPOCH")
.map(sde => new java.util.Date(sde.toLong * 1000))
Rust
Using the chrono
crate:
use chrono::{TimeZone, Utc};
use std::env;
let now = match env::var("SOURCE_DATE_EPOCH") {
Ok(val) => { Utc.timestamp_opt(val.parse::<i64>().unwrap(), 0).unwrap() }
Err(_) => Utc::now(),
};
or
use chrono::{DateTime, NaiveDateTime, Utc};
use std::env;
let now = match env::var("SOURCE_DATE_EPOCH") {
Ok(val) => {
let naive = NaiveDateTime::from_timestamp(val.parse::<i64>().unwrap(), 0);
let datetime: DateTime<Utc> = DateTime::from_utc(naive, Utc);
datetime
}
Err(_) => Utc::now(),
};
Maven
Add the following property in the pom.xml
file:
<properties>
<project.build.outputTimestamp>
${env.SOURCE_DATE_EPOCH}
</project.build.outputTimestamp>
</properties>
Gradle
Set the following properties for the Zip Task that creates the .jar
file:
// Normalizes the ZIP and JAR archives
tasks.withType(Zip) {
preserveFileTimestamps = false
reproducibleFileOrder = true
}
JDK
Builds of OpenJDK version 19 or later support the following new
option in the jar
and jmod
commands:
--date=TIMESTAMP
The timestamp in ISO-8601 extended offset date-time with optional
time-zone format, to use for the timestamp of the entries,
e.g. "2022-02-12T12:30:00-05:00".
Groovy
import java.time.Instant
import java.time.temporal.ChronoUnit
def buildInstant = Instant.now().truncatedTo(ChronoUnit.SECONDS)
def sourceDateEpoch = System.getenv("SOURCE_DATE_EPOCH")
if (sourceDateEpoch != null) {
def epochSeconds = Long.parseLong(sourceDateEpoch)
buildInstant = Instant.ofEpochSecond(epochSeconds)
}
// Creates the timestamp in UTC using the ISO 8601 extended format.
def extendedTimestamp = buildInstant.toString()
Last-resort using faketime
'’As a last resort to be avoided where possible’’ (e.g. if the upstream tool is too hard to patch, or too time-consuming for you right now to patch, or if they are being uncooperative or unresponsive), package maintainers may try something like the following:
debian/strip-nondeterminism/a2x
:
#!/bin/sh
# Depends: faketime
# Eventually the upstream tool should support SOURCE_DATE_EPOCH internally.
test -n "$SOURCE_DATE_EPOCH" || { echo >&2 "$0: SOURCE_DATE_EPOCH not set"; exit 255; }
exec env NO_FAKE_STAT=1 faketime -f "$(TZ=UTC date -d "@$SOURCE_DATE_EPOCH" +'%Y-%m-%d %H:%M:%S')" /usr/bin/a2x "$@"
debian/rules
:
export PATH := $(CURDIR)/debian/strip-nondeterminism:$(PATH)
debian/control
:
Build-Depends: faketime
But please be aware that this does not work out of the box with pbuilder on
Debian 7 Wheezy, see #778462 against
faketime and #700591 against pbuilder
(fixed in Jessie, but not Wheezy). Adding an according hook to
/etc/pbuilder/hook.d
which mounts /run/shm
inside the chroot should
suffice as local workaround, though.
TODO: document some other nicer options. Generally, all invocations of
date(1)
need to have a fixed TZ
environment set.
NOTE: faketime BREAKS builds on some archs, for example hurd. See #778462 for details.
Setting the variable
Debian
In Debian, this is automatically set to the same time as the latest entry in
debian/changelog
, i.e. the same as the output of dpkg-parsechangelog
-SDate
.
-
For packages using
debhelper
versions >= 9.20151004, this variable is automatically exported during builds, so you probably don’t need to change anything. One exception is if yourdebian/rules
needs this variable in non-debhelper parts, in which case you can try (3) or (4). -
For packages using CDBS, versions >= 0.4.131 this variable is also exported automatically during builds, so no changes are needed.
-
With
dpkg
>= 1.18.8 you can eitherinclude /usr/share/dpkg/pkg-info.mk
orinclude /usr/share/dpkg/default.mk
. This was added in Debian bug #824572. -
If none of the above options are good (you should have a ‘‘very good reason’’) then package maintainers may set and export this variable manually in
debian/rules
:
export SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -STimestamp)
If you need/want to support dpkg versions earlier than 1.18.8:
export SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -SDate | date -f- +%s)
If you need/want to support dpkg versions earlier than 1.17.0:
export SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog | grep -Po '^Date: \K.*' | date -f- +%s)
This snippet is believed to work on dpkg versions as far back as 2003.
Git
To set SOURCE_DATE_EPOCH
to the last modification of a Git repository you
can use git log
. For example:
export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
Tool support
We are persuading upstream tools to support SOURCE_DATE_EPOCH
directly. You may help by writing patches for these tools; please add links
to the bug reports here so we know, and to act as an example resource for
future patch writers.
Complete:
- busybox
(
>
1.33.1) - clang
(
>=
16.0.0) - cmake (
>=
3.8.0) - debhelper (
>=
9.20151004) - distro-info (
>=
1.6) - docbook-utils (Debian
>=
0.6.14-3.1, upstream TODO) - doxygen (
>=
1.8.12, Debian pending) - epydoc (
>=
3.0.1+dfsg-8, upstream pending) - gcc
(
>=
7, Debian>=
5.3.1-17, Debian>=
6.1.1-1) - gettext (
>=
0.20) - ghostscript (Debian
>=
9.16~dfsg-1, upstream unfortunately rejected due to additional constraints they have) - groff (Debian
>=
1.22.3-2, upstream pending) - help2man (
>=
1.47.1) - libxslt (
>=
1.1.29, Debian>=
1.1.28-3) - man2html (Debian
>=
1.6g-8, needs forwarding) - mkdocs (
>=
0.16, Debian pending) - ocamldoc (
>=
4.03.0, Debian>=
4.02.3-1) - pydoctor (
>=
0.5+git20151204) - rcc (Qt5
>=
5.13.0, Debian TODO) - rpm upstream
(
>
4.13 other relevant patches linked in there) - sphinx (
>=
1.4, Debian>=
1.3.1-3) - texi2html (Debian
>=
1.82+dfsg1-4, needs forwarding) - texlive-bin (
>=
2016.20160512.41045) - txt2man (
>=
1.5.7, Debian>=
1.5.6-4) - docker buildx (
>=
0.10)
Or you can search in all Debian sources.
More detailed discussion
Sometimes developers of build tools do not want to support
SOURCE_DATE_EPOCH
, or they will tweak the suggestion to something related
but different. We really do think the best approach is to use
SOURCE_DATE_EPOCH
exactly as-is described above in our proposal, without
any variation. Here we explain our reasoning versus the arguments we have
encountered.
(See Standard Environment Variables for general arguments.)
“Lying about the time” / “violates language spec”
This argument arises when the tool processes some input which contains a
static instruction to the effect of “get_current_time()”. The input has a
specification that defines what this means. The tool executes this
instruction, then embeds the result in the output. It is argued that
SOURCE_DATE_EPOCH
would break these semantics and violate the
specification.
In most cases, this argument places too much weight on the absoluteness of
time. Regardless of what any specification says, the user can set their own
system clock and achieve an effect similar to SOURCE_DATE_EPOCH
. Note:
Setting the system clock is not enough for ‘‘reliable’’ reproducible builds
- we need
SOURCE_DATE_EPOCH
for long-running build processes that take varying amounts of time. If the tool was run near the end of the process, then merely setting the system clock would not make timestamps here reproducible. It is not up to the tool to judge whether the user is lying with their system clock, and likewise, it is not up to the tool to judge whetherSOURCE_DATE_EPOCH
is a “lie” or not.
For all intents and purposes, if the user has set SOURCE_DATE_EPOCH
then
they are taking a position that “this is the current time; please use
this instead of whatever clock you normally use”. Yes, the project developer
wrote “get_current_time()” but I as the user, by setting
SOURCE_DATE_EPOCH
, am choosing to override this with my own idea of what
time it is. Please execute the build as if the current time was
SOURCE_DATE_EPOCH
. FOSS software should generally prefer to respect
end-users’ wishes rather than developers’ wishes. (And in practise, we
haven’t seen ‘‘any’’ instance where a project developer really really
prefers “time of build” over “modtime of source”.)
In conclusion, the tool may choose to ignore SOURCE_DATE_EPOCH
for other
reasons, but to judge that this is a ‘‘lie’’ is to disrespect the user’s
wishes. Furthermore, choosing to support this is unlikely to ‘‘actually’’
violate any specifications, since they generally don’t define
“current”. This does not take into account, if the specification needs to
interoperate consistently with other programs in a strong cryptographic
ledger protocol where time values ‘‘must’’ be consistent across multiple
entities. However this scenario is unlikely to apply, in the context of
build tools where SOURCE_DATE_EPOCH
would be set.)
Many tools allow the user to override the “current” date -
e.g. -D__TIME__=xxx
, \\year=yyy
, etc. In these cases, it makes even less
sense to ignore SOURCE_DATE_EPOCH
for data integrity reasons - you
‘‘already’’ have a mechanism where the user can “lie” or “break the spec”;
SOURCE_DATE_EPOCH
would just be adding an extra mechanism that makes it
easier to do this globally across all tools.
If for some reason you’re still conflicted on suddenly changing the meaning
of your “now()” function and desire another switch other than
SOURCE_DATE_EPOCH
being set or not, the texlive
project came up with the
variable FORCE_SOURCE_DATE
; when that environment variable is set to 1
cases that wouldn’t normally obey SOURCE_DATE_EPOCH
will do. We
strongly discourage the usage of such variable; SOURCE_DATE_EPOCH
is
meant to be already a flag forcing a particular timestamp to be used.
OTOH, one alternative we can agree with, that also avoids
SOURCE_DATE_EPOCH
, would be to translate the static instruction
“get_current_time()” from the input format to ‘‘an equivalent instruction’’
in the output format, if the output format supports that.
Interaction of SOURCE_DATE_EPOCH
with automatic rebuilds
When build dependencies change, it is sometimes necessary to rebuild a package without otherwise changing the source. This is especially the case when a security bug is embedded from the build dependency into the build output, as a rebuild is required to fix the security issue. There are, however, many are other situations. Whilst rebuilds of this kind are a manual process in many distributions, some do this automatically.
Debian only performs these rebuilds via a manual developer request called
Binary Non-Maintainer Upload (binNMU). For this, SOURCE_DATE_EPOCH
is
incremented by 1 to avoid creating a situation where two build results
contain files with the same name and the same modification timestamp but a
different content. Not increasing the date breaks rsync
without the
--checksum
option or indeed any transfer/sync/backup process that relies
on the mtime
of files to change to detect underlying content
changes. While it is not generally safe to rely on modification times (and
thus also not to backup systems without --checksum
), we should not
unnecessarily break things.
OpenSUSE performs such rebuilds automatically and also uses something called
“build tree pruning”. Build tree pruning is to discard the output when it is
the same and thus not trigger such rebuilds on packages that build depend on
the discarded output. Normally this works, but if a build e.g. embeds
SOURCE_DATE_EPOCH
in its output, then the output changes every time such a
rebuild happens, which can be very often. This is to be avoided as updating
packages without necessity is too expensive. (The correct solution would, of
course, be to never embed SOURCE_DATE_EPOCH
as so far, no use-case was
found were something else is not better, like instead embed a major version
number. However convincing everyone and changing every instance of this is
an impractical task.)
The following achieves both detecting rebuilds that did not change, despite
a changed build dependency and having an incremented mtime
on files in the
output:
- Use the old
SOURCE_DATE_EPOCH
that was not incremented for the inner build script. - Use the incremented
SOURCE_DATE_EPOCH
for the outer build script which uses it to set the file date after the inner build script is done. - Instead of clamping the file date to
SOURCE_DATE_EPOCH
, set it exactly. This avoids bugs where one of the inner build scripts sets the file date to something earlier, causing two builds to output a file with same date and name, but different content. - Ignore the file date when comparing build output to decide whether to discard for build tree pruning.
History and alternative proposals
1 and the surrounding messages describe the initial motivation behind this, including an evaluation of how different programming languages handle date formats.
We do not have a proposal that includes anything resembling a “time zone”. Developing such a standard requires consideration of various issues:
Intuitive and naive ways of handling human-readable dates, such as the POSIX date functions, are highly flawed and freely mix implicit not-well-defined calendars with absolute time. For example, they don’t specify they mean the Gregorian calendar, and/or don’t specify what to do with dates before when the Gregorian calendar was introduced, or use named time zones that require an up-to-date timezone database (e.g. with historical DST definitions) to parse properly.
Since this is meant to be a universal standard that all tools and distributions can support, we need to keep things simple and precise, so that different groups of people cannot accidentally interpret it in different ways. So it is probably unwise to try to standardise anything that resembles a named time zone, since that is very very complex.
One likely candidate would be something similar to the git internal
timestamp format, see man git-commit
:
It is
We already have SOURCE_DATE_EPOCH
so the time zone offset could be placed
in SOURCE_DATE_TZOFFSET
or something like that. But all of this needs
further discussion.
Other non-standard variables that we haven’t yet agreed upon, use at your own risk:
export SOURCE_DATE_TZOFFSET = $(shell dpkg-parsechangelog -SDate | tail -c6)
export SOURCE_DATE_RFC2822 = $(shell dpkg-parsechangelog -SDate)
export SOURCE_DATE_ISO8601 = $(shell python -c 'import time,email.utils,sys;t=email.utils.parsedate_tz(sys.argv[1]);\
print(time.strftime("%Y-%m-%dT%H:%M:%S",t[:-1])+"{0:+03d}{1:02d}".format(t[-1]/3600,t[-1]/60%60));' "$(SOURCE_DATE_RFC2822)")
The ISO8601 code snippet is complex, in order to preserve the same timezone
offset as in the RFC2822 form. If one is OK with stripping out this offset,
i.e. forcing to UTC, then one can just use date -u
instead. However, this
then contains the same information as the unix timestamp, but the latter is
generally easier to work with in nearly all programming languages.
Introduction
Achieve deterministic builds
- Commandments of reproducible builds
- Variations in the build environment
- SOURCE_DATE_EPOCH
- Deterministic build systems
- Volatile inputs can disappear
- Stable order for inputs
- Stripping of unreproducible information
- Value initialization
- Version information
- Timestamps
- Timezones
- Locales
- Archive metadata
- Stable order for outputs
- Randomness
- Build path
- System images
- JVM
Define a build environment
- What's in a build environment?
- Recording the build environment
- Definition strategies
- Proprietary operating systems