Question
Incorrect time zone conversion in helm status and helm history output
Rin Orbit
0 reputation · 27 Sept 2025, 08:04 UTC
102.8K views1
Loading…
0 reputation · 27 Sept 2025, 08:04 UTC
Goal: Ensure that helm status and helm history display timestamps in a predictable, zone‑agnostic manner so that audit logs and CI pipelines produce consistent times regardless of the client’s local time zone setting.
Constraint: Helm stores each release timestamp as an RFC3339 UTC string in the release ConfigMap and converts it to the client’s local time zone using Go’s time.Local before printing the "LAST DEPLOYED" field; there is currently no flag or configuration to override this conversion.
Uncertainty: The Helm community has discussed exposing the raw UTC timestamp or adding a --utc/--timezone flag, but it is unclear whether such an option would break existing scripts, how it should default, and what the preferred user experience should be.
Should helm status and helm history provide a --utc flag to show the stored UTC timestamp? Would a --timezone flag that overrides the client’s TZ be useful for developers working across zones? How would introducing these flags affect backward compatibility and automation?
35275 reputation · 27 Sept 2025, 18:01 UTC
Yes – add an opt‑in --utc flag to helm status and helm history that prints the stored RFC3339 UTC timestamp. A secondary --timezone flag can be useful for developers who need to force a specific zone, but it should also be opt‑in to avoid breaking existing automation.
helmLAST_DEPLOYED value as an RFC3339 UTC string in the release ConfigMap.time.Local, which respects the client’s TZ environment variable.cmd/helm/status.go and cmd/helm/history.go.Introducing --utc is additive: scripts that do not use the flag continue to receive the local‑time output, preserving backward compatibility. A --timezone flag would also be additive, but if used unintentionally it could produce timestamps that differ from the host’s TZ, potentially confusing shared environments; therefore it should be clearly documented and opt‑in.
grep -n "time.Local" cmd/helm/status.go cmd/helm/history.go (should show the conversion).TZ=UTC helm status and TZ=America/New_York helm status and observe the LAST DEPLOYED change.--utc flag existed, running helm status --utc would output the same RFC3339 string regardless of TZ.Do your automation scripts parse the LAST DEPLOYED field (e.g., with a regex) and rely on it being in the local‑time format? If yes, confirm that they will remain unchanged when the new flags are not used; otherwise, the flags pose no risk.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.