Jira stores every worklog as one instant with a time zone offset. The day it lands on depends on who reads it. On the day the clocks change, the same wall clock can mean two different instants.
How Jira stores a worklog time
The worklog API stores the start as a started timestamp, such as 2026-11-01T01:30:00.000-0700. The format carries milliseconds and a numeric offset with no colon. Jira keeps the offset that the client sent. It does not store a named zone such as America/Edmonton.
A UTC instant shows as a different wall clock in each timezone. The day an entry belongs to depends on the offset of the person who reads it.
One wall clock, two instants
America/Edmonton leaves daylight saving on November 1, 2026. At 02:00 the clocks return to 01:00, and the offset changes from -0600 to -0700. Minutes between 01:00 and 02:00 occur twice that morning.
The fixture below shows both occurrences. Worklog 100302 carries offset -0600 and worklog 100303 carries -0700. Both rows say 01:30 local, yet they are one hour apart as instants.
Which day the hours land on
Download the fixture CSV. ACME-77 is a fictional issue. Mia Chen, Sam Ortiz, and Alex Reyes are fictional people.
| ID | Started (stored) | UTC instant | Day in Edmonton | Day for a UTC viewer | Hours |
|---|---|---|---|---|---|
| 100301 | 2026-10-31 23:30 -0600 | 2026-11-01 05:30 | 2026-10-31 | 2026-11-01 | 2.0 |
| 100302 | 2026-11-01 01:30 -0600 | 2026-11-01 07:30 | 2026-11-01 | 2026-11-01 | 1.5 |
| 100303 | 2026-11-01 01:30 -0700 | 2026-11-01 08:30 | 2026-11-01 | 2026-11-01 | 0.5 |
| 100304 | 2026-11-01 23:30 -0700 | 2026-11-02 06:30 | 2026-11-01 | 2026-11-02 | 4.0 |
| 100305 | 2026-11-02 00:15 -0700 | 2026-11-02 07:15 | 2026-11-02 | 2026-11-02 | 1.0 |
The boundary rows show the difference. Worklog 100301 started at 23:30 on October 31 in Edmonton. A UTC viewer reads the same instant as November 1. Worklog 100304 started at 23:30 on November 1 in Edmonton. A UTC viewer reads it as November 2.
The Edmonton day totals are 2.0, 6.0, and 1.0 hours. All five rows total 9.0 hours.
Why a worklogDate search can drop a boundary day
Jira's worklogDate search buckets worklogs by the site time zone. A site on UTC puts the 23:30 Edmonton entry on November 1, while your Edmonton report counts October 31. A day-boundary entry can then fall outside the window you set.
Daylight handles this in two steps. Its search widens the window by one day on each side, so boundary entries stay in the result. Then it places each worklog on the day its started value falls on in your timezone. The timesheets guide states that Daylight displays entries in your timezone.
Daylight does the bucketing per viewer, so the clock change needs no action from you. Before you submit a week, compare the day column near midnight.
Read a boundary fixture before you trust a day total
- Pick a row near local midnight. Compare the stored offset with the day your report shows.
- On the clock-change day, find two entries with the same wall clock. Make sure that they carry different offsets.
- Add the rows in each day column. Make sure that the totals match the sum you expect.
This walkthrough uses Atlassian's published documentation and Daylight's product source, reviewed on November 1, 2026. The fixture is a worked example, not a customer result or a live Jira trial.
Read the timesheet instructions to see where the grid and the submit controls live.