Yes. Locale changes sort order, date formatting and character encoding, and timezone changes how times are written. If your build uses tools that read them, two machines with different settings can produce different output. Set a fixed locale and timezone inside the build script.
What each setting touches
The reproducible-builds documentation describes three locale effects that matter for builds.
- Time format. Formatting functions can depend on locale variables. The documentation recommends setting LC_ALL directly, since it overrides the others, and notes that the system timezone and TZ variable also change time output.
- Collation order. Sorting is affected by the collation setting. The documentation gives an example in which one European locale sorts independently of case while the C locale sorts by byte value, so the same list of letters comes out in a different order.
- Default character encoding. It affects both input and output of many tools. The documentation shows a text conversion tool producing a different encoding under a different locale, and says the C.UTF-8 pseudo-locale can be used to always get UTF-8 output.
Why this bites small teams
A developer laptop is set to one language and region. CI runners are set to another, often a minimal default. A build step that sorts file names, formats a date or reads a text file can therefore behave differently on the two, and nobody changed any code.
How to set it
Put the settings in the one build script, not in each developer's shell profile, so they travel with the repository.
export LC_ALL=C.UTF-8
export TZ=UTC
C.UTF-8 is available on many Linux systems. On systems where it is not, plain C is always available and sorts by byte value. Check which one your base image and your developers' machines support, then use one value everywhere.
Check for sorting in your build
Sorting shows up in less obvious places: wildcard expansion in a Makefile, directory listings that feed an archive, generated index files and test discovery. The reproducible-builds documentation shows that a Makefile wildcard can sort by the current locale, and fixes it by sorting explicitly or listing inputs by name.
A short test
- Run the build with your normal settings and save the output hash.
- Run it again with a different locale, for example a non-English one, and a different timezone.
- Compare hashes. If they differ, locale or timezone is leaking in.
- Set the fixed values in the script and repeat.
| Setting | Suggested value | Why |
|---|---|---|
| LC_ALL | C.UTF-8 or C | One sort order and encoding |
| TZ | UTC | No daylight saving surprises |
| umask | A fixed value | File permissions in archives |
The same documentation suggests keeping timezones, locales and umasks clean or making sure they do no harm.
Where Safeguard fits
Safeguard is not a build tool, but its SBOM and dependency scanning reads your lockfiles the same way on any machine, which helps you tell locale noise from real dependency change. Free scan: gold.safeguard.sh/scan.
Quick check
Do I need to change developers' own locale?
No. Set the values inside the build script so the build is protected without changing anyone's machine.
Is UTC the one valid timezone for builds?
Any fixed value works. UTC is common because it has no daylight saving changes.
Sources
- Reproducible Builds: Locales
- Reproducible Builds: Stable order for inputs
- Reproducible Builds: Commandments
Last reviewed: 19 October 2026.
