If you have any AI tool generating timestamps in your logs, check the timezone.
I caught this when I cross-referenced a session log with a real-world event I knew the time of. The entry said 14:30. I knew the work happened at 09:30 my local time. Five hours off. Every entry in the log had the same offset. The AI was using new Date() in JavaScript, which gives UTC, not local time.
Why It’s Hard to See
A wrong timestamp looks plausible. 14:30 is a real time. 09:30 is also a real time. There’s no visual signal that one is wrong. Unlike a typo or a missing field, a bad timestamp is structurally valid.
The only way you notice is when you compare to an external anchor. If you only ever read the log in the AI’s company, you’ll never spot it.
The Fix
In session-init hooks, use the shell’s date command, which respects the system timezone:
TODAY=$(date '+%Y-%m-%d')
NOW=$(date '+%H:%M')Pass these into the AI’s context as the canonical time. Don’t trust the AI to generate timestamps from its own runtime.
Bonus: if you’re logging on a server in a different timezone, date will give you server time, not your local time. Set TZ=America/Los_Angeles date if you want the log to match your wall clock no matter where the process runs.
The Larger Lesson
AI-generated metadata is plausible by default and correct by accident. Anything where the format is rigid (timestamps, IDs, slugs, dates) needs an external source of truth. Don’t ask the model to invent it from runtime context. Hand it the value.
Took five seconds to fix. Took a month of misleading logs to notice.