Friday, somewhere after four. The timesheet reminder lands in Slack, and the week in Jira looks like this: Monday logged, Tuesday logged, then nothing. Three days, maybe twenty hours of actual work, and the only record is whatever your memory kept.
Logging work for a previous day in Jira is easy enough: open the ticket, Log work, change the date. Logging three previous days across a dozen tickets is a different job, because first you have to remember what went where. Memory keeps very little. I've done this reconstruction enough times to know the pattern: you remember the big ticket you fought with on Wednesday, you forget the four small ones you closed before lunch, and the review you spent an hour on gets attached to the wrong day. The result looks like a timesheet, but half of it is fiction.
But you don't have to remember. Jira already wrote it down.
What Jira knows about your week
Every time you touch an issue, Jira keeps a timestamped record of it:
- status changes (To Do, In Progress, Done), in the issue's History tab
- every comment you wrote, with its creation time
- field edits: assignee, priority, sprint, estimate, labels
- issues you created
That's a pretty complete trail of which tickets you were on and roughly when. What it's missing is duration. Jira records that you moved a ticket to In Progress at 10:14 and commented on it at 11:50. It has no idea whether you worked on it for those ninety minutes or jumped to something else at 10:20.
So the realistic split is: activity gives you the issues and the order, you supply the hours. Pretending it's more precise than that is how reconstructed logs start reading like fiction again.
The manual version: one previous day at a time
You can do this by hand. Open Jira, search for issues you changed that week, and go through them one by one: the History tab shows when you moved it, the comments show when you wrote something. Lay the tickets out in order per day, drop the ones you only touched for bookkeeping (editing an estimate is not work), and give each one a rounded duration. Keep the day capped at the hours you actually sat there, so eight small touches don't add up to an eleven-hour log. Then log every entry with the date the work happened, not today's: the Log work dialog has a date field, it just defaults to now.
That works. It also takes forty minutes for three days, which is exactly why most people skip it and type "8h, misc" into one ticket instead. If you want the careful version of the method, with the exact search and the tricky cases, I wrote it up here.
The version I built instead: several days at once
I build a desktop time tracker for Jira called Planim Time. It's a menu-bar timer most of the time, but the part that matters for this post is a sidebar called Recent Work, which does the reconstruction above and puts the result on a calendar.
Here's what it does when you open a week that has gaps:
It pulls your trail. Through your own Atlassian account it fetches every issue you changed that week, with its history and comments. It keeps your status moves, comments, field edits and created issues, and throws away the bookkeeping: worklog edits, estimate changes, deleted comments.
It turns touches into blocks. Touches on the same issue that sit close together become one work session. The block starts at your first touch and runs to your last one, and it never crosses midnight or runs into the future. Each block carries a confidence level for where it sits on the clock: a session with a status change at the start and a comment at the end is "high", a single comment at 3 pm is "low" and you should treat the start time as a guess.
It refuses to invent time for bulk actions. If you moved six tickets to Done in ten seconds on Friday afternoon, that is not six work sessions. Those land in the sidebar as candidates with no duration. You can give one a duration if it was real work, or leave it. A ticket that was swept and had real activity that day keeps a single card.
It shows them on the calendar before anything is written. Suggestions appear as ghost blocks on the week grid, next to the worklogs you already have. You can drag one to another hour, resize it, reassign it to a different issue, or dismiss it. The sidebar and the calendar stay in sync, so what you see is what will be logged.
It keeps the day from overflowing. A capacity bar at the top shows logged hours plus proposed hours against your daily target. If suggestions sum past your target, the app trims them rather than letting Wednesday become a fourteen-hour day. The gap to your target stays visible as a gap, instead of being quietly absorbed into the last block.
Then one click. "Add all" creates a draft worklog from every timed block (candidates without a duration are skipped, on purpose). Push sends them to Jira as ordinary worklogs under your account, each dated to the day the work happened, so your Friday push doesn't look like you did the entire week on Friday.
Three days of gaps is a few minutes of looking at the ghosts and nudging the ones that are wrong. Mostly you're confirming durations, which is the one thing the data can't tell you anyway.
The better fix is upstream
Everything above is damage control. The cheap fix is to not have the gap in the first place, and a timer in the menu bar that writes a worklog with the real start time when you stop it does most of that. Idle detection (macOS and Windows) catches the "left the timer running through lunch" case. Recent Work is for the days when you forgot to start it at all, which, for me, is still about one day in ten.
Planim Time runs on macOS, Windows and Linux. It's on the Atlassian Marketplace and at time.planim.app. If you've got a reconstruction trick that works better than reading the issue history, I'd like to hear it in the comments; the sidebar started as exactly that kind of trick.
Top comments (0)