Preserve finish time and planned duration in history #12

New issue

Open

opened 2026-08-17 19:32:01 +00:00 by rosa · 0 comments

rosa commented

2026-08-17 19:32:01 +00:00

Owner

Blocked by: #10

What to build

A Pomodoro read back out of the history should carry the same facts it had when it was archived. Two are lost or corrupted today.

History is written as one record shape and read back as another. The record written on archive has no finish time, so a Pomodoro loaded from history always reports its finish time as null and its actual duration as unknown — even though the finish time is exactly what was used to compute the archived figure.

Worse, that archived figure is the time actually spent, but it is written into the field that means the duration the timer was set for. So a 25-minute Pomodoro stopped after one second comes back as a Pomodoro that was set for one second:

$ tomate pom start -d 1m "no tags given"   # then stop after ~1s
$ tomate history --json
{"pomodoros":[{"started_at":...,"duration":1,...,"finished_at":null}]}

Both figures matter and they are different questions — how long you meant to work, and how long you did. The history should keep both, and tomate history should stay clear about which column it is showing.

Existing history files must keep loading. Decide how a record written under the old shape is interpreted and say so.

Acceptance criteria

An archived Pomodoro records its start time, its finish time, the duration the timer was set for, and the time actually spent
tomate history --json exposes all four, and a loaded Pomodoro reports a finish time rather than null
tomate history's table labels whichever duration it shows unambiguously
History files written by the current version still load, with the old field interpreted according to a documented choice
A round-trip test archives a Pomodoro, loads it back, and asserts every field survives

Blocked by

#10 — that ticket fixes what tomate history --json emits for an empty history; this one changes what it emits for a populated one, and should build on the settled behaviour

Blocked by: #10 ## What to build A Pomodoro read back out of the history should carry the same facts it had when it was archived. Two are lost or corrupted today. History is written as one record shape and read back as another. The record written on archive has no finish time, so a Pomodoro loaded from history always reports its finish time as null and its actual duration as unknown — even though the finish time is exactly what was used to compute the archived figure. Worse, that archived figure is the time actually spent, but it is written into the field that means the duration the timer was set for. So a 25-minute Pomodoro stopped after one second comes back as a Pomodoro that was set for one second: ``` $ tomate pom start -d 1m "no tags given" # then stop after ~1s $ tomate history --json {"pomodoros":[{"started_at":...,"duration":1,...,"finished_at":null}]} ``` Both figures matter and they are different questions — how long you meant to work, and how long you did. The history should keep both, and `tomate history` should stay clear about which column it is showing. Existing history files must keep loading. Decide how a record written under the old shape is interpreted and say so. ## Acceptance criteria - [ ] An archived Pomodoro records its start time, its finish time, the duration the timer was set for, and the time actually spent - [ ] `tomate history --json` exposes all four, and a loaded Pomodoro reports a finish time rather than null - [ ] `tomate history`'s table labels whichever duration it shows unambiguously - [ ] History files written by the current version still load, with the old field interpreted according to a documented choice - [ ] A round-trip test archives a Pomodoro, loads it back, and asserts every field survives ## Blocked by - #10 — that ticket fixes what `tomate history --json` emits for an empty history; this one changes what it emits for a populated one, and should build on the settled behaviour

rosa added the

workflow

ready-for-agent

label

2026-08-17 19:32:09 +00:00