Blog · 3 October 2026

Jira time zone: where it is set, and what each setting changes

To change your Jira time zone, select Settings at the top right, then General settings under Personal Jira settings, and pick a zone under Your timezone. An admin sets the default for everyone else under Settings, System, General configuration, Edit settings, in the internationalization section. Those two settings change how Jira displays times. They do not change the clock Jira Automation runs on, and they do not touch date fields such as a due date. This guide covers each place a time zone lives in Jira Cloud, the daylight saving trap hidden in the dropdown, and how to keep a weekly ticket arriving at 9am local time all year.

Statements about Jira are as of October 2026, from Atlassian's own documentation and its public issue tracker. Atlassian now calls an issue a work item and a project a space. This guide uses the older words where most admins still do.

The short answer: four clocks, four jobs #

Jira has no single time zone. Each of these answers a different question:

The first two are display preferences. Most "Jira shows the wrong time" questions are answered by them. Most "my scheduled ticket arrived at the wrong hour" questions are answered by the last two.

How to change your own Jira time zone #

1. Select Settings (the gear) at the top right of Jira.
2. Under Personal Jira settings, select General settings.
3. Under Your timezone, choose a zone and save.

Atlassian describes the setting as "the timezone used for date and time information across your Jira apps". If the zone you pick doesn't match your computer's, Jira offers to keep it updated automatically, which is worth accepting on a laptop that travels.

Pick a city, never a GMT offset. See the daylight saving section below for why.

How an admin sets the Jira default time zone #

1. Select Settings, then System.
2. Open General configuration and choose Edit settings.
3. In the internationalization section, set the default user time zone.

Atlassian's wording is that this sets "a default user time zone to display across all Jira apps (for example, when looking at work item comments). Users can override this default in their profile." So changing it fixes every user who never touched their own setting, and none of the users who did. If a colleague still sees odd times after the change, their personal setting wins and they need to change it themselves.

The same page carries the sentence that answers a common support question:

Note that date fields such as due dates and release dates aren't impacted by time zone settings.

A due date is a calendar date with no time attached. It reads the same in Sydney and in San Francisco, which is usually what a team wants.

The GMT offset trap: daylight saving that never happens #

The time zone dropdown lists both regions such as America/Vancouver and fixed offsets such as GMT-7. They look interchangeable, and for half the year they are.

Atlassian's own knowledge base article on the problem is direct about it: when the default user time zone is "set to Region GMT, daylight savings changes are not reflected. If you change these settings to a geographic location (Vancouver for example) daylight savings will be accurate." The reason is that a GMT offset is a fixed number. GMT-7 is seven hours behind UTC in July and in January, while Vancouver moves between seven and eight.

So a site set to a GMT offset shows every time one hour off for roughly half the year, and nothing in Jira flags it. The fix takes a minute:

• Admin: change the default user time zone to the city your team is in.
• Each user who chose an offset: change Your timezone to a city too.

Jira Automation: the clock is UTC #

The time zone settings above do not reach Jira Automation. The smart value reference states that {{now}} "returns the current date and time in UTC+00:00". A rule that writes the date into a summary, or adds seven days to set a due date, works from UTC unless you convert it first.

Atlassian's public tracker has an open bug, AUTO-594, about rules writing times converted to UTC. Its description notes this is "not, however, clearly flagged in the automation rule UI, which leads users to assume that the value will match their own timezone", and points at the conversion function as the workaround.

Two date functions exist, and they do different things:

For a title or a due date you almost always want convertToTimeZone. Convert first, then add days, then format: {{now.convertToTimeZone("Europe/Berlin").plusDays(7).jiraDate}}. Our Jira smart values guide walks through the date ones a scheduled rule needs, and setting a due date automatically shows the off-by-one-day bug this causes near midnight.

Scheduled rules and the hour they fire #

The Automation Scheduled trigger runs a rule "at a fixed rate (for example, every 7 days)" or on a cron expression. Atlassian's suggestion AUTO-101 shipped start times and a preview of the next ten runs, and still lists this among its open suggestions:

Timezone support - it would be nice if the cron jobs follow the timezone specified in Jira instance.

In practice that leaves two things to check on any scheduled rule that should fire at a set local hour:

• Which zone the schedule's hour is read in. Look at the next-runs preview before saving and compare it with the local time you meant.
• What happens at the daylight saving change. A schedule pinned to a fixed offset fires an hour early or late for half the year, exactly like the GMT dropdown entry above. Check the preview again in the week the clocks change.

A team in one city that is happy to adjust a rule twice a year can live with this. A team that wants "Monday 9am in Berlin" to mean that every Monday needs a schedule that knows the city.

Recurring tickets that follow local time #

This is the case Recurring Work Items for Jira was built for. Each rule carries its own time zone, chosen from a searchable list next to the time, and it defaults to the zone of the browser that created it. The schedule is then read as wall-clock time in that city, so a weekly review at 09:00 in Europe/Berlin arrives at 09:00 Berlin time in both summer and winter.

The two daylight saving edge cases are handled and written down rather than left to chance:

• A skipped hour. When the clocks jump forward and 02:30 does not exist that night, the rule runs at the first valid moment after the gap. The run history says "daylight saving skipped this time; ran when the clocks caught up".
• A repeated hour. When the clocks fall back and 01:30 happens twice, the rule runs once, at the first. The run history says "daylight saving repeated this time; ran once, at the first".

Dates in a ticket title, such as Weekly review {{now.date}}, are read in the rule's own zone too, so a Sydney team's Monday ticket is dated Monday in Sydney. The tokens reference lists the date tokens and the formats they take.

Two teams in different cities can each have their own rule in the same project, each in its own zone, without anyone converting anything. Runs happen within about five minutes of the chosen time.

Which setting to change, by symptom #

When the built-in settings are enough #

Most teams never need more than the first two rows:

• Everyone works in one city and your recurring work runs on a daily or weekly rhythm where an hour either way does not matter.
• You have a few scheduled rules and someone is happy to check them when the clocks change.
• Your rules write dates, not times, and you already convert {{now}} before formatting.

In those cases set every zone to a city, convert in your rules, and you are done. The Jira Automation examples cover the rule side in more detail.

A dedicated scheduler earns its place when the hour matters: a handover ticket that must exist before a shift starts, an on-call checklist for a team spread over two continents, or a monthly report due at the start of the local working day. For a wider look at the options, see Jira scheduling and Jira recurring tasks.

Frequently asked questions #

Where is the time zone setting in Jira Cloud? Settings at the top right, then General settings under Personal Jira settings, then Your timezone. Admins set the default under Settings, System, General configuration.

Why does Jira show a time one hour off? Usually because the zone is a GMT offset, which ignores daylight saving. Choose a city instead.

Does changing the time zone change due dates? No. Atlassian states that date fields such as due dates and release dates aren't affected by time zone settings.

What time zone does Jira Automation use? {{now}} is UTC. Use convertToTimeZone with a canonical zone ID such as America/New_York to work in local time.

Can each recurring ticket have its own time zone? With Jira Automation, you convert inside each rule. With Recurring Work Items, each rule has its own time zone field and follows daylight saving in that city.