An issue search returns issues. The hours live in the worklogs on each issue. If you total hours from an issue list, you count every worklog on the issue, or none of them. The worklogDate field selects work by worklog date instead.
Pick the date that describes the worklog
The created and updated fields describe the issue. The worklogDate field describes each worklog. The JQL fields reference gives worklogDate = "2010/12/12" as the query for issues where someone logged work on that day.
An updated >= "2026/10/19" search overcounts. ACME-42, the fictional issue in the fixture below, was edited on October 20, 21, and 22 of 2026, so it appears. Its 10 hours from November 2025 also appear in any total you run over the result. An updated window that ends before October 20 hides the whole issue, including its 22 recent hours. Only worklogDate ties the search to the hours.
Mind the time on the boundary
A worklog stores a started timestamp, such as 2026-10-19T22:30:00.000+0000 (worklog API). The value is UTC. Worklog 100203 started at 22:30 UTC on October 19, which is 16:30 in America/Edmonton, so the entry belongs to October 19 there. A team in another timezone can log at 20:00 local on October 24 and see the stored value say October 25 at 02:00 UTC.
Decide which day your total uses before you set the window. Then check the boundary rows in the export, because the last hour of a window is where day and timezone choices show up.
Know the documented search limit
Atlassian documents a search safeguard for Jira Data Center 9.0 and later. The index keeps only the 100 most recent worklogs on an issue, so a worklogDate or worklogAuthor query searches only those entries. Worklogs beyond the limit stay invisible to the query. Atlassian describes a JVM flag and a reindex as the fix. The article applies to Data Center only (worklog JQL knowledge base, updated September 26, 2025).
If one issue on a Data Center site carries more than 100 worklogs, re-check its old totals from the worklogs themselves. A clean worklogDate result on a smaller issue proves nothing about a 600-entry issue.
Read the worklogs when the total matters
For a period total, use the per-issue worklog endpoint. It returns every worklog with its started timestamp and timeSpentSeconds. Read the issues in scope, keep the entries whose started value falls in the window, and add the seconds yourself.
A search result tells you that an issue has work in the window. The hours you report still depend on which worklogs you count.
The fixture
Download the fixture CSV. ACME-42 is a fictional issue. Mia Chen, Sam Ortiz, and Alex Reyes are fictional people. The file carries six worklogs on the same issue: two from 2025 and four from October 2026.
| ID | Started (UTC) | Day (Edmonton) | Person | Hours |
|---|---|---|---|---|
| 100201 | 2025-11-04 09:00 | 2025-11-04 | Mia Chen | 4 |
| 100202 | 2025-11-05 14:30 | 2025-11-05 | Mia Chen | 6 |
| 100203 | 2026-10-19 22:30 | 2026-10-19 | Sam Ortiz | 1 |
| 100204 | 2026-10-20 16:00 | 2026-10-20 | Sam Ortiz | 7 |
| 100205 | 2026-10-21 14:00 | 2026-10-21 | Mia Chen | 8 |
| 100206 | 2026-10-22 21:45 | 2026-10-22 | Alex Reyes | 6 |
The numbers reconcile. The 2025 worklogs total 10 hours. The October 19 to 22 window total 22 hours. Worklog 100203 is the boundary case. It started at 22:30 UTC and still belongs to October 19 in Edmonton. All six worklogs total 32 hours.
Run these checks on a similar fixture before you trust a total:
- The issue appears in a
worklogDate >= "2026/10/19" AND worklogDate <= "2026/10/22"search. - The row days match the day column you use for billing.
- The counted rows add to your window total, and the excluded rows explain the rest.
How Daylight selects worklogs
Daylight reads each issue's worklog list through the per-issue endpoint, bounds it with a startedAfter value, and puts each entry on the day its started value falls on in the team timezone. The per-issue read is also read-after-write consistent, so an entry that you logged a moment ago appears in the same report. Daylight does not use worklogDate search for its totals, so the Data Center indexing limit does not touch them. The reports guide covers the date range and the CSV export.
This walkthrough uses Atlassian's published documentation and Daylight's product source, reviewed on October 25, 2026. It does not report a live Jira trial or a customer result.
Read the reports instructions to see where the date range and export live.