Can I change hours I've already logged in Jira?

Yes. A saved worklog is not locked. In Jira itself you edit it from the worklog entry on the issue, one entry at a time. In a desktop tracker like Planim Time you change it on a calendar: every hour you logged is a block you can drag to a new time, resize to a new duration, or open to fix the comment, and the change is written back to Jira through your own API token.

Can I edit time that was logged by Tempo, Clockify, or another tool?

Yes, as long as you are the author of the worklog. Planim Time pulls every worklog on your issues where you are the worklog author, regardless of which tool created it: Jira's native dialog, Tempo, Clockify, the REST API, or another device. Once it is on the calendar you edit it like any other block. The thing to watch is that if the original tool keeps its own parallel copy of the hours, it can push that copy back over your fix on its next sync.

How do I move logged time from one Jira issue to another?

Jira's worklog has no field for the issue it belongs to, so moving time means deleting the worklog from the first issue and creating a new one on the second. Done by hand that loses the original start time and comment unless you copy them across. Planim Time does the delete-and-recreate for you: open the worklog, pick the new task, confirm, and it moves the duration, start time, and comment to the new issue in one action.

Will editing a worklog in Planim Time change it in Jira too?

Yes, once the worklog has been pushed. When you drag, resize, re-assign, or delete a worklog that is already synced to Jira, Planim Time writes the change straight to Jira through your API token as you make it. A draft you haven't pushed yet stays local until you push it. Sync runs both ways, so an edit you make directly in Jira is pulled back into the calendar the next time you sync instead of being overwritten.

Can I edit my teammates' worklogs?

Not in Planim Time. It edits only worklogs you authored. Other people's hours on the same issue show up on the calendar as read-only context so the day reads correctly, but the app will not change or delete them. Editing someone else's worklog at all is a permission most people don't have in Jira anyway.

How to change logged hours in Jira: edit, move, and delete worklogs in a calendar

The fastest way to change hours you already logged in Jira is to stop opening issues one at a time and put the whole day in front of you. In Planim Time every hour you have logged is a block on a calendar. Drag it to a new time, pull its edge to change the duration, click it to fix the comment, or move it to a different issue, and the change is written straight back to Jira. No hunting for the entry, no retyping a duration into a form.

That matters because correcting time is the part of Jira nobody designed for. Logging the hour is a button on the issue. Changing it afterwards is a small pencil on a single worklog entry, on a single issue, that you have to find first. There is no screen that shows you everything you logged on Tuesday, which is exactly the screen you need when Tuesday’s numbers look wrong.

Why editing in Jira is such a slog

A worklog in Jira lives on one issue, and that issue is the only place you can edit it. So correcting a week means remembering which issues you touched, opening each one, finding the right entry among several, and fixing them one by one. Three things go wrong every time:

You can’t see the shape of a day. The hours are scattered across however many issues you worked, so an obvious mistake (two hours double-logged, a block sitting on the wrong day) stays invisible until someone runs a report and asks about it.
You can’t move time between issues. The worklog has no field for the issue it belongs to, so “I logged this against the wrong ticket” has no edit behind it. You delete the entry and log it again somewhere else, retyping the duration, the start time, and the comment by hand.
You edit blind. The form shows you one entry’s number. It does not show you that entry next to the meeting it overlaps or the commit that proves when you actually started.

None of this is hard. It is just slow, and slow is the reason most people never correct anything and let the wrong numbers stand. Everything below is what we built to take those steps out.

Your logged time, as a calendar

Open the calendar and pick a day or a week. Every worklog you authored shows up as a block on the time grid, placed at its start time, sized to its duration, tagged with the issue key. The day is finally in one view instead of spread across a dozen tickets.

The part that surprises people: this is not limited to hours you logged through Planim Time. We pull every worklog on your issues where you are the author, no matter what wrote it. An hour you logged through Jira’s own dialog, through Tempo or Clockify, through a script against the REST API, or from your other laptop is on the calendar and is editable. The import runs a query for your worklogs by date and author (worklogAuthor = currentUser()), so “mine” means mine regardless of the tool that created it.

Hours logged by other people on the same issues are there too, but as read-only context. You see a teammate’s two hours sitting next to yours so the day reads correctly, and the app will not let you drag or delete them. Their time is theirs to fix.

Change the time: drag and resize

To move a worklog to a different time, drag the block. To change which day it lands on, drag it onto another day in the week view. To change how long it was, grab the right edge and pull. Everything snaps to one minute, which is as precise as a corrected worklog ever needs to be, and because the calendar lives in the menu bar the whole correction happens without a browser tab or a page reload.

The edit applies the moment you let go, and it is optimistic: the block moves on screen first, then it is saved. For a worklog that is already in Jira, that save is written through to Jira right away, and if Jira rejects it the block snaps back to where it was, so what you see on the calendar and what is stored in Jira never quietly disagree.

When you need exact numbers rather than a drag (a worklog that should read precisely 1h 45m, or a comment to rewrite) click the block to open the editor and type. There is also a timesheet grid, an issue-by-day table, where you click a cell and type the hours directly. 1.5, 90m, and 1h30m all parse, and clearing a cell to zero deletes the entry after a confirm.

Move time to a different issue

This is the correction Jira has no answer for, so it gets its own step. Open the block, choose a different task (search reads from your loaded issues and falls back to a Jira search if the key isn’t loaded yet), and confirm. The duration, start time, and comment move across with it.

Here is what happens underneath. Jira’s API has no way to change the issue on an existing worklog, so a move is always a delete on the old issue plus a create on the new one. By hand that is two operations and a full retype. Planim Time runs both as a single action, and if the create half ever fails after the delete half has already gone through, it keeps the worklog as a pending draft on the new issue so you can push it again rather than lose it.

Delete a worklog

Click the block, delete it, confirm. A synced worklog is removed from Jira at the same time, not just hidden from the calendar. The same rule as everywhere applies: you delete your own worklogs, and the read-only ones from teammates stay where they are.

Create one while you’re in there

Correcting a week is rarely only edits. Usually something is missing too. You can click an empty stretch of the grid to drop a new worklog there, type hours into an empty timesheet cell, or pull one of the suggestions Planim Time surfaces from your recent work onto the grid. A new entry pushes to Jira the same way an edit does. The line between fixing a day and backfilling one mostly disappears when both happen on the same grid.

When the edit reaches Jira

Whether an edit lands in Jira right away comes down to one thing: has the worklog been pushed yet. A worklog that is already synced to Jira is edited in Jira as you go. Drag it, resize it, re-assign it, or delete it, and Planim Time writes that change through your own API token the moment you make it, with the rollback above if Jira refuses. A draft you started but haven’t pushed yet stays on your machine: re-time it as often as you like and nothing reaches Jira until you push it. That is also why drafts work offline, since re-timing a block on a plane only touches the local copy until you next sync.

Sync runs in both directions, and that is the part that makes editing safe. If you or a teammate changes a worklog directly in Jira, the calendar pulls that version in the next time you sync instead of stamping over it. That is the opposite of the one-way push model most browser-extension trackers use, where the tool only ever writes to Jira and silently clobbers anything edited on the Jira side. We went into why that breaks for teams in two-way Jira worklog sync.

Which action for which fix

The short version, by the correction you are making:

Wrong duration or start time: drag or resize the block. Nothing to type.
Wrong comment, or an exact duration: click the block and edit.
Logged against the wrong issue: open the block and re-assign it. The app handles the delete-and-recreate.
Double-logged, or on the wrong day: drag it to the right day, or delete it.
Missing entirely: click an empty stretch of the grid and add it.

The four corrections all work on any worklog you authored, including the hours some other tool logged for you, and each one made against a worklog already in Jira lands there as you make it. Creating a missing entry is the exception: it leaves a draft you push like any new worklog. If you have been leaving your Jira hours wrong because correcting them issue by issue isn’t worth the afternoon, that is the friction the calendar removes. Point Planim Time at your Jira and the next time the numbers are off you fix them by dragging a box.