Question
Time zone handling in tmux status line: need for automatic TZ re‑evaluation
Ira Orbit
0 reputation · 09 Jan 2024, 06:57 UTC
102.4K views1
Loading…
0 reputation · 09 Jan 2024, 06:57 UTC
Goal: Determine whether tmux should automatically re‑evaluate the TZ environment variable on each status‑interval tick so that the status line reflects zone changes without restarting the server.
Currently tmux reads TZ once when the server starts and uses that value for all subsequent strftime calls; the update‑environment option only propagates TZ to newly created windows, leaving existing panes with stale timestamps when the system time zone changes. An open discussion in the tmux mailing list (circa 2021) questions whether this behavior should be changed, but no resolution has been reached.
What are the performance costs of checking TZ on every status‑interval update? How would automatic TZ updates impact user workflows that depend on stable timestamps? Should tmux introduce a configurable flag to enable or disable dynamic TZ re‑evaluation?
When a tmux server starts it reads the TZ environment variable once and caches the resulting offset. All later strftime calls – including those that render the status line – use this cached value. The update-environment option only propagates the variable to new windows; existing panes keep the stale offset until the server is restarted.
tmuxtzset() on every status‑interval tick adds a few microseconds of CPU time per tick.status-interval values (1–5 s) the overhead is <0.01 % of a single tick’s cycle time, even on modest hardware.Introduce a new tmux option – set -g status‑tz‑dynamic on|off – that defaults to off (the current behaviour). When enabled, tmux will call tzset() on each status‑interval tick, thereby keeping the displayed time in sync with the system TZ. The implementation is straightforward, the performance cost negligible, and the toggle gives users control over whether they want dynamic or stable timestamps.
status-interval 1 using the patched code to confirm the microsecond overhead.TZ while the pane is active, and compare the file timestamps to the status line.update-environment semantics.Until the option is merged, the practical workaround remains a server restart or re‑source of tmux.conf after a TZ change.
Use comments to ask for clarification. Post a solution as an answer.
31,275 reputation · 09 Jan 2024, 11:26 UTC
While the CPU overhead of calling tzset() is negligible, it is important to clarify that this function often triggers file I/O to read /etc/localtime or /etc/timezone. In environments with network-mounted filesystems (like NFS or certain containerized volumes), frequent disk reads on every status-interval tick could introduce unexpected latency or I/O wait, especially if the interval is set to 1 second.
To verify the current behavior in a running session, you can compare the server's cached time against the shell's current environment:
# Check shell time
date
# Compare with tmux status line (assuming %H:%M:%S format)
# If they differ after a system TZ change, the server is using cached data.If a dynamic flag is implemented, it should be noted that tzset() affects the entire process. Any internal tmux logging or timestamps used for server-side events would also shift, which may complicate log analysis for administrators tracking server-wide events across time zone transitions.