← Documentation index

Timezones

Unless the build timezone is made part of the build environment, care must be taken to get the build output when the build is run in two different timezones.

Avoid writing the current timezone

Some tools will write date and time with the associated timezone:

$ LC_ALL=C date -d'@2147483647' --rfc-2822
Tue, 19 Jan 2038 04:14:07 +0100

Despite being given a pre-determined time in the form of a Unix time (also called epoch), this output would fail to be reproducible in a different timezone than UTC+0100. The easy solution is to set the required environment variable to force tools to use UTC as the timezone:

$ LC_ALL=C date -u -d'@2147483647' --rfc-2822
Tue, 19 Jan 2038 03:14:07 +0000

When there is no dedicated option, it is most often possible to set the TZ environment variable:

$ TZ=UTC LC_ALL=C date -d'@2147483647' --rfc-2822
Tue, 19 Jan 2038 03:14:07 +0000

Note that both TZ=UTC and TZ=UTC0 styles are valid. Chapter 8 of the POSIX standard specifies a number of formats:

  • :characters
  • std offset dst offset, rule
  • “a format specifying a geographical timezone or a special timezone”

UTC0 matches the second one and UTC matches the third.

The main benefit of UTC0 is that it is fully specified in POSIX; on any POSIX-compliant system, TZ=UTC and TZ=UTC0 will mean the same thing. TZ=UTC relies on the implementation, however; typically it would use the IANA database (which is mentioned in POSIX), but there’s nothing stopping an implementation from interpreting TZ=UTC as the timezone of a putative “United Transcendental Countries” for example.

A related concern is for formats which don’t contain timezone information. Zip archives are a good example: the same timezone must always be used to unpack them to prevent variations on the file modification times.

Use date string with timezone information

Time strings like “Wed, 21 Oct 2015 11:18:50” are inherently ambiguous. Which timezone does it use? How should it be understood?

In the context of reproducible builds, it’s best if time strings all contain timezone information. A fallback option is to assume they are all specified as UTC.

If time strings without timezone specification are parsed in the timezone of the build system, hard to understand behavior might happen. An example is doing time difference computations in timezones with different daylight saving changes. As different timezones have different policies, a user might get more or less hours depending on the timezone used to perform the build.

← Documentation index

Documentation home

Introduction
Achieve deterministic builds
Managing variance
Define a build environment
Distribute the environment
Verification
Specifications