Buildroot Git Timestamps: Trace the Default Epoch Before Comparing a Checkout with a Snapshot

A Buildroot Git checkout and an exported source snapshot can select different default build epochs even when their ordinary source files match. Before blaming a package for changed date fields, inspect how the top-level build obtained SOURCE_DATE_EPOCH. The selected value is an input to the comparison, not automatically the time you started compiling.

This guide pins Buildroot 2026.08 with BR2_REPRODUCIBLE enabled. It addresses the top-level default-selection rule, rather than every package's timestamp handling. The scenarios below are proposed checks; no Buildroot execution or reproducibility result is claimed.

Read the implemented fallback chain

The tagged top-level Makefile obtains a Git timestamp with log -1 --format=%at. If SOURCE_DATE_EPOCH has not already been set, the default uses that result when available, otherwise the release epoch recorded in the Makefile. This selection occurs inside the reproducible-build condition.

The source comment calls it a commit date, but the Git pretty-format reference identifies %at specifically as the author's Unix timestamp. It is distinct from the committer timestamp represented by %ct. When investigating a rebased or cherry-picked history, avoid treating those two dates as interchangeable.

Record the actual numeric epoch and its origin: supplied value, Git-derived author time or release fallback. A source revision label alone leaves this part of the build environment unexplained.

Compare the checkout and archive cases deliberately

For a hypothetical comparison, prepare one checkout and one exported snapshot with matching relevant source files. Keep the output directories separate. First inspect whether each build can discover repository metadata, then observe the selected epoch without assuming both paths use the release constant.

A snapshot outside any Git repository can take the release fallback when no Git timestamp is produced. An exported tree placed inside another repository needs extra attention: absence of a .git directory directly inside the snapshot is not sufficient evidence that Git discovery cannot find repository context above it.

Use the Git rev-parse reference to inspect the resolved top-level repository and Git directory from the build's source location. If the context belongs to a surrounding project, investigate that relationship before explaining the timestamp as the Buildroot revision's date. This is a diagnostic risk to check, not a claim that every nested snapshot necessarily produces the same outcome.

Preserve the meaning of an explicit epoch

A controlled release process may supply an epoch deliberately. Confirm that the actual build invocation receives the intended value and record the release policy that selected it. Do not replace it casually with today's date just because a generated file looks old.

The SOURCE_DATE_EPOCH specification defines a deterministic Unix-time input for cooperating build tools. It is not a promise that every arbitrary generator obeys it, nor a representation of the device's future runtime clock. Keep source-date policy separate from event timestamps and actual test execution times.

If a supplied value is missing or malformed, resolve that configuration problem through the build policy. Quietly inventing a different date during an investigation makes the comparison less controlled and can hide the original failure.

Use a small provenance matrix

For each proposed comparison, record repository discovery result, checked-out commit when applicable, author timestamp, release fallback, supplied epoch and resolved value. Include BR2_REPRODUCIBLE so the recorded rule actually applies to the run under examination.

Then compare only the outputs relevant to the reported difference. If the selected epochs differ, first explain that input difference. If they match but generated bytes still differ, investigate the consumer or another input; the selection rule has not established complete reproducibility.

A useful regression covers a checkout, a snapshot outside a repository and the deployment packaging layout actually used by the team. Inspect the real subprocess environment rather than relying solely on an interactive shell's variables. Keep proposed checks distinct from executed evidence.

The practical outcome is a traceable timestamp choice. A matching source tree, a Git identity and a build epoch are related records, but none should silently substitute for the others when explaining a changed artifact.