The Date Picker Moves Both Ways

"A forgotten symptom files to last Tuesday. A planned training block scatters into next month. The timeline is unbounded in both directions."

Both Directions, on Purpose

Same-day entry is never forced in Forge. The composer's date picker moves in both directions: backward — a symptom Dad forgot to log files to last Tuesday, and a 2025 check-up scanned today files under 2025 — and forward — a scheduled appointment or a planned training block scatters into the future. Selecting another day sets the crumb's target_date without pretending the crumb was submitted then. The act of writing it down and the date it belongs to are two different facts.

Retrospective Is Normal Here, Not an Edge Case

This matters more in health than in most domains, because medical records arrive weeks after the visit they describe. A check-up result is a PDF you upload today for a visit that happened last month; a supplement list is a screenshot of a regimen already running. If retrospective filing were an awkward special path, half of Forge's real content would fight the tool. So it is a first-class motion, not a workaround — the Medical tab in particular assumes it.

The date picker moves both directions; captured is not owned. Setting a different day changes only target_date — the day the crumb belongs to for reading and filing — never captured_at, which stays the true moment of writing. Late filing is normal; back-dating the capture itself is not.

One Guardrail: No Silent Re-Dating

There is a single careful rule around this. A non-empty persisted draft is never silently re-dated when Dad taps a calendar day — that would quietly move work he already started. Tapping a day gives an empty composer that date as its filing target; an in-progress draft only takes the selected date when Dad applies it explicitly. The engine will scatter a crumb anywhere on the timeline, but it never moves one without being told to.

Code

Written today, owned by another day — captured_at never lies·json

// A symptom Dad forgot, filed today to last Tuesday:
{
  "captured_at":   "2026-07-24T21:40:00+09:00",  // true write moment
  "target_date":   "2026-07-21",                 // the day it belongs to
  "text": "forgot to note it - left wrist ached Tuesday morning"
}

// A planned training block, scattered forward:
{
  "captured_at":   "2026-07-24T21:41:00+09:00",
  "target_date":   "2026-08-04",                 // future
  "text": "start the new 3x lower-body block"
}
// captured_at is frozen truth; target_date is where it files.

Exercise

Think of a health fact you know happened but cannot pin to today — a check-up last spring, an injury a few years back, an appointment coming up. In a today-only logging app, where does it go? In Forge, which date does it get, and which field stays fixed at the moment you actually wrote it down?

Hint

In a today-only app it either gets the wrong date or gets lost. In Forge it takes a target_date of when it belongs, while captured_at stays honest about when you filed it.

The Date Picker Moves Both Ways

Both Directions, on Purpose

Retrospective Is Normal Here, Not an Edge Case

One Guardrail: No Silent Re-Dating

Code

External links

Exercise

Progress

Comments 0