Two small settings for a genuinely common annoyance
Claude Code shows timestamps in a few places: the done 6:05 PM line that closes out a turn's duration message, and the per-message timestamps in the transcript viewer. Until Claude Code v2.1.257 (1 September 2026), those times always followed your system locale and your machine's local time zone, with no way to change either without changing the whole machine's settings. That's a real problem for anyone running Claude Code across time zones, recording a screen capture for a support ticket or a demo where a consistent UTC timestamp matters, or just preferring a 24-hour clock regardless of locale defaults.
timeFormat and timeZone, both added in that release, fix this with two independent settings. timeFormat decides how a time is written; timeZone decides which time zone it's written in. They combine, with one exception covered below.
Setting timeFormat
Run /config and set Time format to pick one of the built-in presets. timeFormat accepts:
| Value | What it produces |
|---|---|
"auto" (default) | Unchanged from before this setting existed: each time keeps its built-in format, following your locale for the turn duration message |
"12-hour" | A 12-hour clock |
"24-hour" | A 24-hour clock |
"24-hour-utc" | A 24-hour clock in UTC with a trailing Z, for example 18:05Z. This preset ignores timeZone entirely |
A strftime pattern, such as "%H:%M" | Claude Code writes each time using the pattern. Any value containing a % counts as a pattern; anything else outside the four presets above is treated as "auto" |
/config only offers the four presets. To use a strftime pattern, add the key directly to a settings file:
{
"timeFormat": "%H:%M"
}
With that pattern, the turn duration message and the transcript viewer both show times like 18:05. In the transcript viewer, the pattern becomes the entire timestamp, so if you want a date alongside the clock, include date directives in the pattern yourself:
{
"timeFormat": "%Y-%m-%d %H:%M"
}
That produces timestamps like 2026-09-04 18:05 throughout the interface, which is useful if you're pasting transcript excerpts somewhere the date matters and the surrounding context won't make it obvious.
Setting timeZone
timeZone shows interface times in a zone other than your system's. Set it to an IANA time zone name:
{
"timeZone": "Europe/Dublin"
}
Or use "UTC" directly if you just want a fixed reference zone without the DST behaviour a named zone like Europe/Dublin carries. The times that timeFormat controls then render in whichever zone you set. There's no /config row for timeZone, unlike timeFormat, so it has to be set in a settings file rather than through the interactive menu.
If Claude Code doesn't recognise the name you give it, it falls back to your system time zone rather than erroring, so a typo in an IANA name degrades quietly instead of breaking the session. Worth double-checking the exact spelling against the IANA database if times don't look like you expected after setting it.
How the two interact
The one place they don't combine is the 24-hour-utc preset. If timeFormat is "24-hour-utc", times stay in UTC no matter what timeZone is set to, and Claude Code ignores the timeZone key for that preset specifically. Every other timeFormat value, including a custom strftime pattern, respects whatever timeZone you've set. So the combination for "always UTC, in a 24-hour format" has two equivalent routes: set timeFormat to "24-hour-utc" alone, or set timeFormat to "24-hour" (or a pattern) alongside timeZone: "UTC". Either gets you there; the preset is just the shortcut that doesn't require touching timeZone at all.
Where to set it: scope matters here
Both settings accept any settings file scope, which means the choice of where you set them changes who it affects:
- User settings (
~/.claude/settings.json): your personal preference, follows you across every project on this machine. - Project settings (
.claude/settings.json, committed): applies to everyone working in this repository, useful if a team standardises on UTC for shared session logs or screen recordings that get attached to tickets. - Project-local settings (
.claude/settings.local.json, not committed): your own override for this one repository, without imposing it on collaborators. - Managed settings: an organisation can set either key as policy, for example forcing
timeFormat: "24-hour-utc"across every machine so support tickets and audit logs from different engineers are directly comparable without a mental time zone conversion.
That last case is probably the strongest argument for either setting existing at all: a distributed team filing bug reports, screen recordings, or transcript excerpts benefits enormously from every one of them carrying the same, unambiguous timestamp format, rather than each engineer's local clock and locale producing a different string for the same moment.
A worked example: standardising on UTC for a support team
A team that triages Claude Code issues by reviewing transcript excerpts from engineers across several time zones might set this in a shared, committed project settings file:
{
"timeFormat": "24-hour-utc",
"timeZone": "UTC"
}
The timeZone line here is redundant given the preset, included only for clarity to a reader who might otherwise wonder whether it needs setting separately. Every timestamp any engineer's session produces, from the turn duration line to a transcript export, now reads in the same unambiguous 18:05Z form regardless of where that engineer is sitting.
Common strftime patterns worth knowing
If you're setting a custom pattern rather than one of the four presets, these are the directives you'll reach for most often:
| Directive | Meaning | Example |
|---|---|---|
%H | Hour, 24-hour, zero-padded | 18 |
%I | Hour, 12-hour, zero-padded | 06 |
%M | Minute, zero-padded | 05 |
%p | AM/PM | PM |
%Y | Four-digit year | 2026 |
%m | Two-digit month | 09 |
%d | Two-digit day | 04 |
%Z | Time zone abbreviation | UTC |
A pattern like "%I:%M %p" reproduces the same output as the "12-hour" preset, so patterns are really for the cases the presets don't cover: including the date, dropping leading zeros with platform-specific directives, or appending the zone abbreviation with %Z so a timestamp is self-describing even outside Claude Code's own interface.
Why this matters more than it looks like it should
On its own, a timestamp format is a cosmetic detail. It stops being cosmetic the moment a timestamp leaves Claude Code's interface and travels somewhere else: pasted into a Slack thread reporting a bug, embedded in a screen recording attached to a support ticket, or quoted in a written incident postmortem. In every one of those cases, a reader with no context for your local time zone or locale has to guess what a bare time actually means. A team that standardises timeFormat and timeZone in a committed project settings file removes that guesswork permanently, which is a small thing individually but compounds across every transcript, ticket, and recording a distributed team produces over time.
Troubleshooting
My strftime pattern isn't being applied. Confirm the value actually contains a % character. Claude Code treats any timeFormat value without one, other than the three named presets, as equivalent to "auto", so a typo that drops the % silently falls back to locale-default formatting instead of erroring.
/config doesn't show a row for time zone. That's expected. Only timeFormat has a /config entry; timeZone has to be set directly in a settings file, at whichever scope you want it to apply.
Times still show my system zone after setting timeZone. Check for a typo against the IANA time zone database first. An unrecognised name falls back to your system zone rather than failing loudly, so a misspelled zone can look like the setting simply isn't working.
I set timeZone but nothing changed. Check whether timeFormat is set to "24-hour-utc". That preset ignores timeZone entirely by design, so if you actually want a specific non-UTC zone, use "24-hour", "12-hour", "auto", or a strftime pattern instead.
The feature seems to not exist at all. Both settings require Claude Code v2.1.257 or later. Check your version with claude --version and upgrade if you're on an older release.
Where this fits among Claude Code's settings
timeFormat and timeZone are small settings, but they're a useful example of a broader pattern worth knowing: Claude Code increasingly separates "what the interface looks like for me" from "what the interface looks like for everyone on this project," through the same settings file scoping that governs permission rules, hooks, and MCP server configuration. For the full reference of every setting Claude Code accepts, see the settings reference, and for how these settings interact with automated, unattended runs where a consistent timestamp matters most, see how Claude Code Routines differ from /loop and how to self-host Claude Code runners.