[rudycelekli]

Why

An incremental Jira sync asks for updated >= "<last successful sync start>", formatted from a UTC timestamp as yyyy-MM-dd HH:mm. Jira does not read that literal as UTC. A JQL date with no zone is read in the time zone of the account running the search (Atlassian KB, and the developer community answer that walks through the conversion).

The auth_header belongs to a person, and that person's profile is usually in their own zone. For a US Eastern account (UTC-5), a sync that last started at 12:34 UTC asks for updated >= "… 12:34". Jira reads that as 12:34 Eastern, which is 17:34 UTC. Tickets updated between 12:34 and 17:34 UTC are never fetched. Every later window starts after them, so they stay missing until someone edits them again. Accounts east of UTC only re-read some tickets, which ingestion already deduplicates.

The same bug in another Jira client: gastownhall/beads#3788.

What changes

The window is written as a relative period, updated >= "-90m": the minutes since since, rounded up and at least 1. Jira's documented relative format is measured from the server's now, so the account's zone does not enter. Rounding up means the window can only widen. The project clause, quoting and ordering are unchanged, and a first sync still has no updated clause.

#1359 (open) reworks the Jira checkpoint and keeps jql(). Its checkpoint is also a UTC instant, so it would hit the same shift. Whichever lands second only needs to keep this formatting.

How it was checked

• the_incremental_jql_uses_jiras_own_time_format now builds since as 89 min 40 s ago and expects updated >= "-90m". The comment above it gives the UTC-5 case.
• cargo test -p utopia-server --bins jira: 5 passed.
• With the fix reverted, the test fails on project = KAFKA AND updated >= "2026-10-24 20:56" ORDER BY updated ASC.
• cargo fmt --all --check and cargo clippy -p utopia-server --all-targets -- -D warnings pass.

Before review

• Every commit is signed off (git commit -s)
• cargo fmt --all --check, cargo clippy and cargo test pass for the touched crate

[WaylandYang]

The bug is real, but a relative window is evaluated again on every startAt page. If paging takes longer than the rounding margin, tickets at the window edge drop out and later pages skip that many, permanently. Please either format since in the account's zone from /rest/api/2/myself timeZone, or keep the absolute format with a safety margin. Please also pass now into jql for a deterministic test, note the time-zone trap in ADR 0013 §3, and coordinate with #1359.

[WaylandYang]

One more reason for the absolute bound: with #1359, the reader skips rows at or before the stored checkpoint and checks the listing again before it commits. A relative -Nm bound is re-evaluated on every page request, so the window's start moves during paging and that check fails the run. An absolute bound written in the account's time zone (from /rest/api/2/myself) works with it.