Today I Learned - Zsh History Timestamps

What it is

A DFIR note on Zsh command-history timestamps and how they behave differently on a live session versus after the history is flushed to disk. Zsh is the default shell on Kali, Gentoo, and macOS (since Catalina). The practical payload beyond the summary is the full set of fc timestamp flags and their output formats.

How it works

During an active session Zsh holds each command in memory alongside a timestamp of its actual execution time, viewable with fc. Once the session closes or the box reboots, the entries persisted to ~/.zsh_history lose those per-command execution times — in the author's limited testing the timestamps collapsed to what looked like the session-open time. So a live-system pull can yield accurate per-command timing that a dead-box acquisition of ~/.zsh_history cannot.

What to do

On a live system, dump history with timestamps before the session ends:

fc -lf
fc -li 100

The fc built-in exposes several timestamp formats (from the zshbuiltins man page) — pick per investigation:

• -d — prints timestamps for each command
• -f — full date-time, US MM/DD/YY hh:mm format
• -E — full date-time, European dd.mm.yyyy hh:mm format
• -i — full date-time, ISO8601 yyyy-mm-dd hh:mm format
• -D — elapsed times; combinable with one of the above

For future readiness, make timestamping persistent by setting HISTTIMEFORMAT in the shell profile.

Caveats

• The reset-to-session-open behavior is the author's observation from "limited testing," not a documented guarantee — treat on-disk ~/.zsh_history timestamps as unreliable rather than assuming a specific fallback value.
• The timeline-reconstruction value only exists while the session is live; capture history before logout/reboot or you lose per-command timing.
• The page recommends HISTTIMEFORMAT for Zsh, but note this is conventionally the Bash timestamp variable; verify the correct persistence mechanism for your target shell before relying on it.