时区如何影响 Jira 状态时长和趋势报表

时区不会改变 Jira 流转发生的时刻，但不同的时区控件承担不同职责。在 StatusPath Reports 中，所选 Calendar 时区属于 Jira 工作流报表 Business Calendar 定义，并定义工作时间计算和 Trim History 日期所使用的本地边界；Status Time Trend 的时间桶优先使用 Jira 用户上下文加载的报表展示时区，无法取得时再依次回退到浏览器和 Calendar 时区。必须同时记录两个时区：切换 Calendar 可以改变图表数值，但不会改变定义横轴时间桶的时区；不过，当某个 Calendar 使时间桶中没有可绘制时长时，可见横轴标签集合仍可能变化。

分开记录日历时区和趋势时区

StatusPath 从 Jira changelog 历史读取流转时间戳。Atlassian 记录了工作项 changelog API，并在 Jira Cloud REST API 时间戳说明中说明顶层时间戳使用 ISO 8601 表示，同时提供按登录用户时区渲染字段的选项。做算术前应保留偏移量，或把时间戳归一化为同一时刻。

Jira 展示和搜索还有各自的时区上下文：

• 登录用户可以在 Jira 个人设置中选择 Jira 应用显示日期时间所用的时区。
• Jira 管理员可以设置站点的默认用户时区，用户可以覆盖该默认值。
• Atlassian 的 JQL 字段参考说明，受支持的日期字段会使用执行搜索用户配置的时区；用户未设置时使用 Jira 默认时区。

这些上下文不会替代所选 StatusPath Calendar。Calendar 时区控制工作时间交集；StatusPath 会在可用时使用 Jira 当前用户时区作为报表展示和趋势分桶时区，无法取得时再回退到浏览器时区和 Calendar 时区。JQL/搜索时区、Calendar 时区和报表展示时区必须作为三个独立输入记录。

可复现 Jira 场景：UTC 与上海

本例使用可复现 Jira 报表场景中的演示工作项。

一个工作项在 2026-07-06 16:30Z 进入 In Review，在 2026-07-07 09:30Z 离开。该区间的自然时间为 17 小时。比较两套周一至周五 09:00-17:00 工作日历：

保持 Jira 工作项范围、状态、完整历史窗口和 Decimal Hours 格式不变，只切换所选日历。

UTC 结果：1 个工作小时

在 UTC 中，该区间与两个短工作时段相交：

上海结果：8 个工作小时

同一组时刻在 Asia/Shanghai 中为 7 月 7 日星期二 00:30-17:30。本地区间覆盖完整的 09:00-17:00 工作日：

1 小时和 8 小时都符合各自书面日历定义，都不表示 Jira 改写了流转历史。

固定趋势展示时区后读取趋势

UTC 的两个半小时区间可以核对表格结果，但面积图不是这两个区间的逐段图示。本次可复现运行保持 Jira/报表展示时区和所选状态集合不变，只切换 Calendar：

UTC 截图中可以看到 To Do 和 Done 数值，而上海截图只绘制了 In Review。记录的配置保持所选状态集合不变；差异来自切换 Calendar 后哪些已配置系列仍有非零绘制值，并不表示两次运行之间选择或清除了状态。空时间桶和零值系列可能不会显示。此次验收只比较 7 月 7 日的 In Review。图表视图文档说明当前支持的趋势周期和单位。

时区会在哪些位置改变报表含义

工作时间纳入

同一个时刻在一个时区可能位于工作时间内，在另一个时区则位于工作时间外。因此，只改显示偏移量并不等于切换工作日历。

日期范围和 Trim History 边界

7 月 7 日在 UTC 和 Asia/Shanghai 中从不同的时刻开始。StatusPath 使用所选工作日历时区确定 Trim History 日期边界；Jira JQL 日期值则遵循 Jira 搜索时区规则。两者必须分开记录，详见 Jira Time in Status 日期范围如何裁剪历史。

每日、每周和每月时间桶标签

StatusPath 会在可用时从 Jira 当前用户解析趋势展示时区，然后依次回退到浏览器和所选 Calendar。接近午夜的事件在展示时区改变后可能移动到不同日、周或月；仅切换 Calendar 不能证明横轴时区已经改变，即使部分时间桶因不再包含可绘制时长而使可见标签集合发生变化。

与 Jira 原生报表比较

Atlassian 的配置工作日页面说明，公司管理型看板设置包含时区，并反映在指定 Jira 报表和小组件中。Control Chart 文档适用于公司管理型空间，并按所选工作流状态计算 cycle time 或 lead time。它与 StatusPath 逐状态趋势是不同指标和配置界面，比较前必须对齐定义。

夏令时切换

区域时区可能在夏令时边界改变 UTC 偏移量。长期报表不要用固定偏移量替代区域时区；适用地区应在每次时钟切换两侧各验证一个已知区间。

可重复的时区比较流程

1. 从 Jira 工作项历史或 Jira changelog API 记录包含偏移量的流转时间戳。
2. 记录 Jira/报表展示时区，并固定工作项范围、状态集合和历史窗口。
3. 选择 Decimal Hours 和第一套已命名 Calendar。
4. 逐段核对一个表格行。
5. 把趋势周期、报表展示时区、可见时间桶标签和状态值作为独立图表检查项记录。
6. 只切换 Calendar，不修改 JQL、Trim History、状态、筛选或展示时区。
7. 重复表格检查，并比较同一展示时区时间桶中的同一状态；单独记录可见标签差异，因为空时间桶可能在展示时区不变时消失。
8. 如果问题针对时间桶日期，则把 Jira/报表展示时区作为独立实验修改，并保存两套配置。

常见错误

比较本地时间文本，而不是时间线时刻

带有不同偏移量的两个时间戳可能表示同一时刻。相减前应先归一化。

把一个时区同时当成两个控件

所选 StatusPath Calendar 定义工作排班；Jira 用户时区可以提供报表展示和趋势分桶时区。必须分别记录，而不能假设其中一个会静默覆盖另一个。

混用 JQL 日期和日历日期

JQL 工作项范围遵循 Jira 搜索语义；StatusPath Trim History 和工作时间边界遵循所选报表配置。

把趋势变化解读为工作量变化

Calendar 变化可以改变时长，展示时区变化可以改变时间桶边界。把趋势差异解释为工作变化前，必须同时固定两者。

忽略夏令时边界

固定 UTC 偏移量无法代表会调整时钟的地区在所有日期的时间。应使用目标区域时区，并验证受影响周期。

常见问题

修改时区会改变 Jira 历史吗？

不会。它改变同一组事件时刻周围的本地显示和计算边界，不会改写流转本身。

工作流报表应使用哪个时区？

Calendar 应使用指标所代表运营排班的时区，同时记录趋势标签使用的 Jira/报表展示时区。多地区服务可能需要按地区建立不同日历，或采用一套明确批准的运营定义。

为什么 17 小时区间在 UTC 中是 1 小时，在上海是 8 小时？

工作时间是事件区间与本地工作时段的交集。UTC 版本只接触两个半小时边缘，上海版本则跨越一个完整本地工作日。

Jira 用户时区会覆盖 StatusPath Calendar 吗？

不会。它不会替代工作排班。Jira 用户时区可能影响 Jira 展示、搜索解释以及报表趋势的分桶上下文；所选 StatusPath Calendar 控制工作时间交集。

可以把可见趋势点相加来还原一个表格行吗？

不要直接这样假设。表格是逐工作项合计，Status Time Trend 则按配置的时间桶呈现累计状态时间。应先用区间算术核对表格行，再根据趋势周期、展示时区、工作项范围和状态选择单独验证图表。

相关指南

• Jira 工作流报表 Business Calendar 完整指南
• 如何计算 Jira Cloud 中的状态停留时间
• Jira Time in Status 日期范围如何裁剪历史
• 如何在 Jira 状态时间中排除周末和非工作时间
• Jira 工作流报表中的夏令时时间边界问题

在每个时长和趋势旁保留时区

缺少 Calendar 时区和报表展示时区中的任何一个，状态时长或趋势都不完整。前往 Atlassian Marketplace 试用 StatusPath Reports，用已批准的区域日历呈现同一段 Jira 历史，并把两个时区输入与边界核对结果保留在报表旁。