zsh history includes a timestamp.

Beyond knowing when a command was executed, what's the reason for this? What features might I lose if I disable this?

closed as unclear what you're asking by Thomas Dickey, Mikel, Stephen Rauch, GAD3R, Romeo Ninov Oct 22 '17 at 6:05

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Why isn't that sufficient reason? – Mikel Oct 21 '17 at 11:47
  • Sure, but if thats the only reason. I'd happily disable it. – ideasman42 Oct 21 '17 at 12:02

zsh history includes a timestamp, if the EXTENDED_HISTORY feature is enabled, or if the SHARE_HISTORY feature is enabled; in the latter case, timestamps are used so multiple shells can read each others’ history accurately — they only need to read any new commands added since the last time they read the history file, and they can do so even when the history file is rewritten.

These features are enabled or disabled using setopt:

setopt extendedhistory
setopt sharehistory

will enable them, while

setopt noextendedhistory
setopt nosharehistory

will disable them.

If you want to keep shared histories, you’ll need to keep the extended timestamps (but you don’t need to explicitly enable the EXTENDED_HISTORY feature; the SHARE_HISTORY feature is self-sufficient).

Note that extended history tells you not only when a command was executed, but also how long it took to run, which can be useful in some cases.

The History section of the documentation has all the details.


If I recall correctly, ZSH uses the time stamp to reorder the historical commands when you have more than one session opened.

Not the answer you're looking for? Browse other questions tagged or ask your own question.