Filed Here, Written Then

"Selecting an earlier day files the crumb under that date without pretending it was submitted then."

The Model's Truth Has to Reach the Surface

Keeping two dates in the database is only half the job. If the interface shows only one of them, the user's head quietly re-collapses the model — they see a single date on a card and assume it means 'when I wrote this', even when the crumb was backdated. The two-truth rule has to be visible, or it isn't really honored. So when a crumb's target_date differs from the day its captured_at falls on, Vesta's card shows both, plainly: filed to one day, written on another.

When the two agree — the common case, a crumb captured today about today — showing both would be noise, so the card shows one date. The rule is simple and it keeps the surface calm: show one date when the truths agree, show both the moment they diverge. The interface never invents a date and never hides the divergence; it mirrors exactly what the model knows.

If the model separates two truths, the UI must not silently merge them. A careful backend and a lazy surface still produce a lying product, because the user only ever sees the surface. Divergence that exists in the data must be legible in the interface — otherwise you've paid for the second field and thrown away its value at the last inch.

Local Dates Are Explicit, Never Guessed

There's a quieter trap the surface has to avoid: inferring a local date at read time. If you store only a UTC instant and compute 'which day was that?' whenever you render, the answer drifts with the reader's current time zone — a crumb written at 11pm in one zone can jump to the next day when viewed from another. Vesta refuses that: local dates and time zones are captured explicitly at write time and stored, never re-derived on read. The day a crumb was written is a fact fixed the moment it happened, not a calculation that changes depending on where you're standing when you look.

Code

Show one date, or both — but never a guessed one·typescript

function crumbDateLabel(crumb: Crumb): string {
  const writtenDay = crumb.captured_local_date; // stored, not inferred
  const filedDay = crumb.target_date;

  // truths agree -> one calm date
  if (writtenDay === filedDay) return filedDay;

  // truths diverge -> show both, honestly
  return `filed ${filedDay} \u00b7 written ${writtenDay}`;
}

// captured_local_date is stored at write time, so 'written' never
// shifts when a reader in another timezone opens the card later.

Exercise

Design the smallest honest label for a dated item that carries a written-moment and a belongs-to day. Write the rule for when to show one date versus two, and decide what the label says when they differ. Then stress-test it: what does your label show for a crumb written at 11:45pm and filed to 'yesterday'? Make sure the reader is never misled about which date is which.

Hint

The hard case is near-midnight backdating, where written and filed are one day apart and easy to confuse. Label each date with its role (filed / written), not just the number — a bare 'Mar 13 · Mar 14' tells the reader nothing about which is which.

Filed Here, Written Then

The Model's Truth Has to Reach the Surface

Local Dates Are Explicit, Never Guessed

Code

External links

Exercise

Progress

Comments 0