Spack logs show install timestamps in local time zone

Direct answer

Spack has no built-in setting to store or display install timestamps in UTC. The intended approach for cross-region analysis is to normalize times yourself: either run builds with TZ=UTC so the host clock is already UTC, or convert existing logs to UTC using the known offset of each machine. Spack itself records timestamps with the host's local clock.

Confirmed behavior vs. likely explanation

Confirmed: Spack generates install timestamps using Python's datetime.now(), which returns a naive local-time value. That value is written into build logs and into environment metadata such as .spack/environment.yaml. There is no configuration key or environment variable that changes this to UTC.

Likely explanation: Because the stored value is naive—no timezone offset is attached—downstream tools cannot tell which zone a timestamp came from. This is a long-standing design choice in the logging path, not a recent regression, and it means any cross-region comparison requires external knowledge of the originating host's zone.

Steps for this case

1. If you control the build hosts, set TZ=UTC before invoking spack install. The naive timestamp will then match UTC.
2. For logs already written, convert each timestamp to UTC by applying the original host's UTC offset. Since Spack does not record that offset, you must track it separately (for example, in your CI metadata).
3. If you aggregate environment metadata from multiple sites, apply the same conversion before merging or sorting by install time.

Verification

Confirm the behavior on your installation with these checks:

# Compare a recent build log timestamp with the host clock
ls -t ~/.spack/var/spack/logs/*.log | head -1 | xargs tail -5
date

# Inspect environment metadata for naive local-time fields
grep -i timestamp .spack/environment.yaml

# Optional: run a short install on two hosts and compare
spack install zlib
date -u
date

The log timestamp should match date output, not date -u, unless TZ=UTC is already set.

Patching the source

It is technically possible to edit Spack's logging module to call datetime.utcnow() instead of datetime.now(), but this is not an official configuration path. Doing so can break scripts or dashboards that expect local-time strings, and it will not retroactively fix logs that are already written. Treat this as a local fork decision, not a supported feature.