Issue Summary

Running CHANGED DURING/CHANGE ON JQL with minute-precision date/time literals on issue history (e.g. status changes) intermittently omits matching issues when the change occurs in the last second of the end minute (second 59). The same change is returned if the JQL end bound is moved to the next minute, which indicates an off‑by‑one error in how the upper bound of the range is interpreted.

Steps to Reproduce

1. In a Jira Cloud site, create an issue (for example, key "EX-1").
2. Change the issue's Status at a time that falls in the 59th second of a minute in your profile time zone, for example:
   1. Change occurs at approximately `2025-01-01T10:23:59.xxx` in the user's configured time zone.
   2. (This can be verified via the REST API using `expand=changelog`)
3. In the issue navigator, run a JQL query that uses CHANGED DURING with minute-precision bounds that should include that change, for example:
   1. `status CHANGED DURING ("2025-01-01 10:22", "2025-01-01 10:23") AND key = EX-1`
4. Observe that the query returns {}no results{}, even though the issue's status changed inside the specified range.
5. Now adjust the JQL end bound to the next minute, for example:
   1. `status CHANGED DURING ("2025-01-01 10:22", "2025-01-01 10:24") AND key = EX-1`
6. Observe that the same issue is now returned, even though the only relevant status change is still the one at approximately `10:23:59`.

Expected Results

• When using CHANGED DURING with minute-precision date/time literals, Jira should normalize the bounds so that the entire start and end minutes are included in the range.
• Conceptually, for a query such as:
• `status CHANGED DURING ("2025-01-01 10:22", "2025-01-01 10:23")`
  the effective time window should be:
• lower bound: `>= 2025-01-01T10:22:00.000`
• upper bound: `<= 2025-01-01T10:23:59.999`
• Therefore, a status change occurring at `10:23:59.xxx` should be included in the results when the end bound is `"2025-01-01 10:23"`.

  Actual Results

• For changes that occur in the last second of the end minute (e.g. `10:23:59.xxx`), CHANGED DURING with an end bound equal to that minute fails to return the issue.
• The issue is only returned when the end bound is moved to the next minute (e.g. `"2025-01-01 10:24"`), indicating that:
• the underlying implementation is effectively doing:
• `event_timestamp >= start AND event_timestamp < end`
• instead of correctly expanding a minute-precision end value to the next minute (or equivalently including the entire end minute, up to `:59.999`).
  The below exception is thrown in the xxxxxxx.log file:

  No exception is thrown. The query executes successfully but returns no matching issues, despite a qualifying change existing in the specified minute.
  

Workaround

Currently there is no known complete workaround for this behavior. A workaround will be added here when available.
Partial mitigations:

• When constructing CHANGED DURING filters where precise inclusion of the last minute is important, set the end bound to the next minute. For example:
• Instead of `status CHANGED DURING ("2025-01-01 10:22", "2025-01-01 10:23")`
• Use `status CHANGED DURING ("2025-01-01 10:22", "2025-01-01 10:24")`
• This ensures that changes occurring in the last second of the intended end minute are included, but it may also include changes that occur in the additional minute, so it is not a perfect replacement for correct minute-bound semantics.