Bash History With Timestamp

Adding timestamps to your bash history

The default .bash_history file stores commands but strips any notion of when they ran. That works fine until you need to figure out which command kicked off that process that is currently eating all your CPU. Then you are stuck guessing. Setting HISTTIMEFORMAT in your .bashrc changes that behavior across the board. Add this line to your .bashrc or .profile: HISTTIMEFORMAT="%F %T "

Then reload with source ~/.bashrc. After that, running history will prepend each entry with a date and time stamp in YYYY-MM-DD HH:MM:SS format. The format string follows standard strftime syntax, so if you want something different like just the hour and minute, you can swap it to "%H:%M " instead. The catch nobody mentions is that HISTTIMEFORMAT only affects the display. The actual file on disk still stores commands without dates. The timestamps are injected at read time by the history builtin using the current system clock. This means if you transfer your .bash_history file to another machine and run history there, the timestamps will be wrong because each machine uses its own clock for generation. I ran into this exact problem last year when I pulled my history from a staging server to investigate a deployment script that had run three days earlier. Every entry looked like it executed yesterday because I was reading it on my workstation. The workaround was to copy the file and immediately run history on the source machine before transferring anything.

Common pitfalls and what to watch for

If you set HISTTIMEFORMAT but history still shows no dates, check whether histFileSize or similar overrides exist in your .bashrc. Some configurations also use HISTCONTROL=ignorespace or ignorespace:erasedups which can cause commands to disappear from the log entirely regardless of timestamp settings. Another thing to keep in mind is history file size. Once timestamps start logging, your .bash_history grows roughly twice as fast because each entry now carries a full date string before the command itself. On a machine where you run scripts frequently, that can mean hundreds of megabytes within a few months. I once had a server where the history file hit 800MB and bash became noticeably sluggish opening new sessions because it was parsing that entire file on startup. The fix was adding a rotation script that truncates anything older than 90 days. If you need per-command execution time rather than just a wall clock timestamp, that requires a different approach entirely. You would need PROMPT_COMMAND set to log timestamps before each prompt renders, or use something like bash-logger or auditd depending on your needs. HISTTIMEFORMAT alone will not give you durations or execution windows.

The feature is straightforward but has real limitations around portability and file growth. Use it for local investigations. Do not rely on it for auditing or compliance workflows since the timestamps are not embedded in the file itself and can be altered by moving the file between systems.