Timezones in Jira reporting: why dates look off

[#1]

If you have ever opened a Jira report and thought, “That issue was resolved on Tuesday. Why is the chart insisting it was Monday?” — welcome. You have met timezones, one of software’s most loyal pranksters. They do not break your data. They just stand in the corner, quietly moving the meaning of “today” by a few hours and letting the team argue about it. Atlassian’s own documentation makes it clear that Jira and Atlassian Analytics do not rely on a single universal timezone everywhere, which is exactly why reports can look “off by one day” even when nothing is technically wrong.

The uncomfortable truth: Jira does not have one timezone

The first thing worth accepting — perhaps with tea, or something stronger — is that there is no single “Jira timezone” that rules everything.

Different parts of the stack can use different timezone logic:

• the site default timezone
• the user’s personal timezone
• the board timezone
• UTC-based handling for some date values
• UTC storage in Atlassian Analytics
• and, in reporting apps like Time in Status, the calendar timezone used for calculations

That is why one person can say, “The report is wrong,” and another can say, “No, the data is correct,” and somehow both are right. It is not a contradiction. It is just software architecture with a sense of humor.

Why dates look wrong even when the data is right

Most date problems in Jira reporting are really boundary problems.

A timestamp created at 23:30 UTC can still belong to “today” for one user and “tomorrow” for another. If your chart groups data by day, your JQL starts at midnight, your dashboard converts to viewer-local time, or your workflow report uses a business calendar, the same event can land in a different bucket depending on which timezone layer is doing the interpretation. Atlassian says JQL date searches are relative to the configured timezone and assume midnight when no time is provided, which is a wonderfully efficient way to create confusion near day boundaries.

In other words, the issue is usually not “bad data.” The issue is “whose midnight are we talking about?”

The five places where timezone confusion usually starts

1. User timezone vs site timezone

Atlassian says admins can set a default user timezone for Jira, and users can override it in their own profile. Public and anonymous users inherit the site’s default preferences. So even before you open a dashboard, Jira may already be showing the same work item differently to different people. That is normal behavior, not a glitch.

What this means in practice:

• one user sees a timestamp as late evening
• another user sees the same event as early next morning
• both export the data
• both become newly interested in “how Jira actually works”

Atlassian documentation: Configure Jira app options, Manage your Jira personal settings, JSM - Manage your Jira personal settings.

2. Date-only fields vs datetime fields

This is where many teams get ambushed.

Atlassian’s issue-view documentation says that date values, including Date Picker fields, are displayed in UTC. Atlassian even recommends using a Date Time Picker when users are spread across multiple timezones and the exact moment matters. That is a polite way of saying: a plain date field is not built to carry all the emotional weight of cross-timezone reporting.

That matters because fields like these often look simple:

• Due Date
• Start Date
• Date Picker custom fields

But simple-looking fields can cause messy outcomes when they are:

• compared to datetime values in automation
• grouped into daily buckets in reports
• interpreted by users in different regions

A date without a time is not neutral. It is just incomplete in a very confident way.

Atlassian documentation: Date and time formats.

3. JQL filters

JQL is often where the argument begins because it looks precise.

A filter like resolved >= "2026-03-10" feels obvious, but Atlassian says JQL search results are relative to the configured timezone, and if you do not specify a time component, Jira assumes midnight. That means the filter is not asking for a universal truth. It is asking for “everything after midnight in the relevant timezone context.” Those are not the same thing.

That is why JQL problems often show up as:

• “why is this issue missing from today’s report?”
• “why does my teammate get different numbers?”
• “why did this ticket move from Tuesday to Monday in the export?”

The answer is often not “Jira is wrong.” It is “your filter had an invisible timezone inside it.”

Atlassian documentation: JQL fields.

4. Boards and sprint reporting

Board-based reporting adds another layer. Atlassian documents that Jira boards use Working days settings, including a board timezone, for reports and gadgets such as Sprint Report, Burndown, Epic Report, Version Report, and Control Chart. So if your board timezone differs from the user timezone, you can end up with slightly different stories about the same sprint.

That is usually when a team says something like:

• “the sprint closed on the 30th”
• “then why does this chart show the 31st?”
• “let us all take a walk before we continue this meeting”

A healthy instinct, frankly.

Atlassian documentation: Configure working days, How your plan handles timezones.

5. Atlassian Analytics

Atlassian Analytics is explicit about one important detail: date and timestamp columns in the Atlassian Data Lake are stored in UTC. Then the workspace timezone, dashboard timezone, or viewer-local timezone can affect how those timestamps are displayed later. Atlassian also says relative date variables follow the dashboard timezone on dashboards, but the data source timezone outside dashboard context. That means one query can behave differently depending on where it runs.

This is why all of the following can be true at once:

• the raw query says March 9
• the dashboard says March 10
• the viewer in Berlin sees one day
• the viewer in New York sees another

And yes, everyone involved may still be technically correct. This is not comforting, but it is accurate.

Atlassian documentation: Workspace settings, Dashboard settings, What are variables?

How to diagnose an “off by one day” report

When a Jira report looks wrong, run through this list before blaming the data, the app, or Mercury in retrograde.

Ask these questions first

• Is this a date-only field or a datetime field?
• Is the value being shown in the user timezone, site timezone, board timezone, dashboard timezone, or UTC?
• Is JQL assuming midnight because no time was provided?
• Is automation using {{now}}, which Atlassian says returns UTC by default?
• Is Atlassian Analytics converting times to the viewer’s local timezone?
• Is the issue close to midnight, sprint start/end, month end, or a DST change? These are the usual crime scenes for timezone bugs. The last point is partly inference from the documented behavior above, but it is a very safe one.
  
  

The fastest fixes

If you want fewer timezone surprises, these habits help immediately:

• Use datetime fields when the exact moment matters, not just the day. Atlassian explicitly recommends Date Time Picker for cross-timezone use cases.
• Be explicit in JQL when boundaries matter. Add the time component instead of trusting plain dates.
• Standardize dashboard timezone settings in Analytics for shared reporting, instead of letting every viewer discover reality independently.
• Document the timezone owner for each report: site, user, board, calendar, or dashboard. 

Where Time in Status fits in — and why it actually helps

This is where the story gets more useful.

A lot of Jira reporting tells you when something happened. But teams often care more about how long something stayed that way. That is a different question, and it needs different timezone logic.

According to SaaSJet’s documentation, Time in Status uses two timezone sources:

• the calendar timezone to calculate durations in statuses and transitions
• the user’s Jira timezone to display Jira date-time fields and Status Entrance Date values

That split is smart, because calculation and display are not always the same problem.

For example, if a work item changes status at 5 PM in one timezone, SaaSJet notes that it may already be the next day in another timezone, which changes how the duration is mapped in reports. In other words, Time in Status lets you calculate using the calendar that actually reflects your team’s work schedule, instead of hoping raw timestamps will magically behave like business hours.

That is especially useful for teams that need to answer questions like:

• How long did issues stay in In Progress?
• How much time was spent in Review, QA, or Waiting for Support?
• When did an issue first enter Ready for Testing?
• Are we measuring work in real calendar time or real working time?

And if your team lives in sprint retrospectives, the Time in Status Sprint Report is worth a look too. SaaSJet describes it as a sprint analysis view based on the board’s JQL scope, with support for active sprints as well as completed ones. That makes it easier to line up sprint performance with the time actually spent moving through the workflow, which is often more revealing than a simple issue count.

So the gentle reminder is this: when your real question is about time spent, handoff delays, status aging, or working-calendar-based metrics, a calendar-aware app like Time in Status is not just a nice add-on. It solves a different class of reporting problem.

A calmer way to think about timezone problems

Here is the deeper lesson.

Instead of asking, “What date is this?” ask, “According to which timezone, at which layer, for which purpose?”

That is the difference between casual reporting and grown-up reporting. A date in Jira is rarely just a date. It is usually:

• a stored value
• a display rule
• a grouping rule
• a calculation rule
• and, if neglected long enough, a meeting

Once teams understand that, timezone issues stop feeling random. They start feeling explainable. Still annoying, of course. But explainable.

Conclusion

Dates look off in Jira reporting because different parts of Jira and Atlassian Analytics treat time differently: site settings, user preferences, board configuration, UTC-based storage, and app-specific calendars all have a say. Atlassian’s documentation spells out those layers, and SaaSJet’s Time in Status docs show why workflow metrics become more accurate when calculations are tied to the right calendar timezone instead of whatever display setting happens to be active.

So the fix is not to force one timezone on everything. The fix is to be intentional:

• decide which timezone controls each report,
• use datetime fields when exact moments matter,
• be explicit in JQL and Analytics,
• and use calendar-aware reporting when the real question is about time spent in the workflow.

And if your team is tired of asking, “Why is this date wrong again?” it may be time to review your reporting setup — and, if workflow timing matters, take a closer look at Time in Status. Sometimes the most important reporting question is not what day it happened, but what actually happened during the hours that mattered.