Jira Time in Status 日期范围如何裁剪历史

Jira 报表中的日期范围可能有两种含义。Work item date range 或 JQL 决定哪些工作项进入报表；在 StatusPath Reports 中，Trim History 决定每个已选工作项的哪段 changelog 参与计算。把 Trim History 设为 UTC 时区的 7 月 1 日至 3 日后，只计入与这三个完整自然日重叠的区间；完全位于窗口前后时长均为零。更完整的状态时长计算模型参见如何计算 Jira Cloud 中的状态停留时间。如果工作项范围来自 Board 和 Sprint，请按 Sprint 范围的 Time in Status 配置指南核对成员范围，并与本页的历史窗口规则分开验收。

分别定义工作项选集和计算窗口

这些控件回答不同的问题：

Atlassian 说明，高级搜索使用 JQL 查找工作项。JQL 运算符参考还记录了 CHANGED、DURING、FROM 和 TO 等历史条件。这些条件用来识别匹配工作项，不会计算时长列。

底层历史来自 Jira。Atlassian 说明，工作项的 Activity 区域可以显示 History，其中包括字段编辑和工作流移动。应用可以通过 Jira Cloud REST API 的 Get changelogs 接口，按日期顺序读取工作项 changelog。下文的 Trim History、重叠裁剪和 Date To 行为是经过核查的 StatusPath Reports 行为，不是 Jira 原生报表功能。

可复现的 Jira 测试场景：三天发布评审窗口

发布经理希望比较三个发布检查日内产生了多少 In Review 时长，而不以 Story 的创建或解决时间限制总体。六个 SR 工作项覆盖全部关键边界：完全位于窗口前、跨过开始边界、完全位于窗口内、跨过结束边界、跨越整个窗口，以及完全位于窗口后。截图使用 Jira 测试项目中的合成演示数据。

使用以下可复现报表定义：

具体产品控件见报表设置与范围和日历与时长。All time (UTC) 是为本可复现场景配置的 24×7 UTC 日历，并不表示每个安装环境默认都带有这个名称的日历。生产环境应使用管理员配置的等效日历，并记录其工作时间与时区。

StatusPath 按所选 Work Calendar 的时区解释 Trim History 两个日期。Date From 从所选日历日期的开始处起算，Date To 则包含该日历日期的完整一天。使用已配置的 24×7 UTC 日历时，7 月 1 日至 3 日会计算这三天中的全部时间，完整窗口显示为 72.00 小时。如果使用其他 Calendar 时区，相同日期的边界也会移动；遇到夏令时切换时，本地自然日还可能短于或长于 24 小时。

计算每个裁剪后的状态区间

对一个已结束的状态区间，使用以下公式：

计入时长 = max(0,
  min(状态结束时间, 窗口结束时间) - max(状态开始时间, 窗口开始时间)
)

把规则应用到六个 In Review 区间：

In Review 计入时长的人工合计为：

0.00 + 36.00 + 8.00 + 12.00 + 72.00 + 0.00 = 128.00 小时

Decimal Hours 格式把四个非零单元格显示为 36.00、8.00、12.00 和 72.00；StatusPath 使用破折号显示零时长状态单元格，因此产品表格中的两行零值不会显示成 0.00。SR-3102 的 48 小时中有 12 小时发生在 7 月 1 日之前，因此准确计入 36 小时。

配置并核查报表

1. 先写出总体问题

先决定工作项成员条件是“SR 项目中的全部 Story”“7 月解决的工作项”，还是“7 月流转到 In Review 的工作项”。这句话决定数据源、JQL 和可选的 Work item date range，而不是 Trim History。

例如，以下 Jira 查询选择在该时段流转到 In Review 的工作项：

project = SR
AND status CHANGED TO "In Review"
  DURING ("2026/07/01", "2026/07/04")
ORDER BY key ASC

Atlassian 说明，Jira 会按照执行搜索的用户所配置的时区，把没有时间部分的日期解释为零点；如果用户没有设置，则使用 Jira 系统时区。StatusPath Calendar 不会改变 Jira 的搜索语义。只有当该 Jira 搜索时区正是预期的总体筛选时区时，才能把以上查询视为 7 月 1 日至 3 日，并应把它与 StatusPath 计算时区分别记录。

只有当流转事件本身决定成员资格时，才应这样使用 JQL。它可能排除 SR-3102 和 SR-3105：两者的 In Review 区间都在 7 月 1 日之前开始，但仍有一部分时长与窗口重叠。要保留本裁剪分析中的全部六行，应使用场景 JQL project = SR ORDER BY created ASC，并保持 Work item date range 为空。

2. 设置计算窗口

开启 Trim History，在 Date From 中输入 2026-07-01，在 Date To 中输入 2026-07-03，然后应用。Trim History 只改变已选工作项参与计算的历史，不会把已经被选集条件排除的工作项重新加入报表。控件操作顺序见报表设置与范围。

3. 固定日历和显示格式

在本场景中，选择已配置的 All time (UTC) 24×7 日历，让每个自然小时都参与计算，并让日期边界位于 UTC 零点。使用 Decimal Hours，以便直接对照表格和人工计算。工作日历或其他时区会构成不同的计算定义；日历与时长说明了这些控件如何配合。

4. 在 Jira History 中检查两个边界

打开有代表性的工作项，查看 Activity → History。确认进入 In Review 和下一次离开 In Review 的流转时间。对 SR-3102，先确认裁剪前完整区间为 48 小时；对 SR-3104，确认完整区间为 24 小时。在该 Trim History 窗口下，报表应分别显示 36.00 小时和 12.00 小时。

5. 对账结果表

分别检查零时长、部分时长、完整时长和跨全窗口四类结果。正确表格会在 SR-3101 和 SR-3106 显示破折号，并在另外四行显示 36.00、8.00、12.00 和 72.00；人工合计为 128.00 小时。只有在总体、Trim History 范围、Calendar、时区和 Format 一起记录后，才保存或导出结果。

常见错误

把 Work item date range 当成 Trim History

Created、Updated 或 Resolved 日期筛选可以移除整行，但不会决定该行有多少状态历史被计入。应使用 Trim History 裁剪区间。

把 status CHANGED 当作重叠判断

status CHANGED TO "In Review" DURING (...) 查找在时段内发生进入事件的工作项，可能漏掉更早进入 In Review、但在窗口开始后仍持续的区间。

把 Date To 只当作零点

在本 StatusPath 配置中，Date To 2026-07-03 包含所选 Calendar 时区中的完整 7 月 3 日。如果误当成 7 月 3 日的开始处，窗口会错误漏掉当天的贡献。

混用 UTC 和本地时区

无时间部分的 JQL 日期边界遵循执行搜索的用户在 Jira 中设置的时区；未设置时使用 Jira 系统时区。Trim History 日期边界则遵循所选 StatusPath Calendar 的时区。误以为一个控件会同时设置两者，可能改变工作项总体或部分时长。业务问题要求相同日期时应对齐两个时区，否则应记录它们为何不同。

比较自然时间和工作时间

本场景配置的 All time (UTC) 日历计算每个小时。工作日历可能排除夜间、周末或节假日，因此不应期待它复现人工核查的 128.00 小时合计。

对已经舍入的行值求和

如果显示格式会舍入时长，可见单元格之和可能与基于未舍入区间的总计不同。人工核查时应使用 Decimal Hours 并保留时间戳精度。

常见问题

Jira 日期范围会自动裁剪状态历史吗？

不会。JQL 和 Work item date range 选择工作项；在 StatusPath Reports 中，Trim History 独立裁剪参与计算的历史。

工作项在 7 月 1 日之前进入 In Review，为什么仍有部分时长？

因为 In Review 区间一直持续到 Trim History 窗口内。只计入重叠部分，并不要求进入事件必须发生在窗口内。

Date To 包含所选日期吗？

包含。StatusPath 会按照所选 Calendar 的时区包含 Date To 的完整日历日期。使用本场景配置的 24×7 UTC 日历时，7 月 1 日至 3 日的完整窗口显示为 72.00 小时。

JQL CHANGED DURING 能替代 Trim History 吗？

不能。它可以根据变化事件定义工作项总体，但不会把每个匹配状态区间裁剪到该时段，也不会计算时长。

如何核查一条结果？

读取 Jira Activity → History 中的流转时间戳，还原完整区间，与 Trim History 窗口求交集，再应用与报表相同的 Calendar 和时区。

对于仍未关闭的区间，当前状态时长指南说明了如何用单日 Trim History 边界让稍后的运行保持可复现。

相关指南

• 如何列出上月离开 To Do 的 Jira 工作项
• 为什么 Jira 当前状态的停留时间会持续增长
• 如何计算 Jira Cloud 中的状态停留时间
• 如何使用 JQL 创建 Jira Time in Status 报表
• 时区如何影响 Jira 状态时长和趋势报表
• 如何查找 Jira 工作项进入某个状态的日期

让每个报表边界都可审核

只有把工作项总体和计算窗口放在一起，状态时长才容易被信任。StatusPath Reports 可以选择 Jira 工作项，通过 Trim History 裁剪历史，复核部分时长，再保存或导出已经审核的配置。