Three Days Ago, Not the Twelfth of September

Why this product never shows you a date, what that trade actually costs, and the bug where sixty-five things spread over two months all read “just now.”

Date

/

Category

Perception

Perception

/

Writer

Keon Hwui Kim

Keon Hwui Kim

My father has a photograph of his own father that he can date to within a week, and he cannot tell you the year.

He knows it was taken after the move and before the winter that the pipes froze. He knows what he was doing that season. Given ten seconds and a calculation involving his own age, he can produce a number, and the number is always the last thing to arrive.

This is how memory actually indexes, and almost no software respects it.

A page of handwritten field notes

Fig. 1. University of Edinburgh Heritage Collections, CC BY 3.0, via Wikimedia Commons.

The decision

JEFIELD never shows you a date. Not on a card, not in the detail view, not in a search result. It shows 3일 전, 지난주, 두 달쯤 전. Elapsed time, always, everywhere.

People ask about this more than almost any other decision, usually as a complaint. Here is the reasoning, including the part where it costs something.

You do not remember in calendar coordinates

Try it. Think of something you made a few months ago. An actual piece of work, something with a shape you can picture.

You did not arrive at a date. You arrived at a season, a project, a period. Around the time of that deadline. Before the trip. Early in the year, when it was still cold.

The date is a lookup you perform afterwards, from context, if you happen to need it. It is not how the thing is stored.

So a date on a card is, for the act of recognition, an encoding. Accurate, sortable, and requiring a small translation every single time you read one. You have to convert 12 September into about a week ago before it means anything, and you perform that conversion silently, dozens of times a day, without noticing you are working.


Absolute date

Elapsed time

Precision

Exact

Coarse and degrading

Reading cost

A conversion every time

None

Stable over time

Yes. Never changes

No. Changes every day

Sortable by eye

Yes

Yes

Good for

Records, contracts, scheduling

Recognition, judging distance

Bad for

Judging distance from now

Finding a specific known day

Table 1. Neither is better. They answer different questions.

What elapsed time gives you instead

Distance. Immediately, with no arithmetic.

And distance is the thing carrying meaning here. Three days ago and three months ago are different kinds of object, not different values of the same one. One is still warm. It is part of what you are currently doing, and you have context for it loaded. The other has cooled into something you would be rediscovering rather than continuing.

A calendar date flattens that difference into two equivalent strings of similar length and identical typography. Elapsed time preserves it in the only unit that matters: how far from now.

A date tells you when it happened. An interval tells you where it stands in relation to you.

The cost, which is real

You lose precision, and precision is occasionally exactly what you need.

If you are looking for the file from a specific meeting on a specific afternoon, 두 달쯤 전 is useless and a date would have solved it instantly. Legal and financial material needs dates. Anything that will be referenced by someone else needs dates.

I accepted the trade because the precise case is rare in this product and has a good fallback, which is search that reads what the thing actually says, and the recognition case is constant. But it is a trade, not a free win, and I would rather say so than pretend the decision had no downside.

There is also a subtler cost that took me a while to articulate. Elapsed time is not stable. The same card says different things on different days. That is correct behaviour and it makes the interface impossible to screenshot for documentation, hard to write tests against, and confusing in any context where two people are looking at the same item and one of them opened it yesterday.

A small bug that made the point better than the argument did

While building a demo corpus with two months of history in it, every item read 방금. Just now. All sixty-five of them.

The cause: the system clamps timestamps forward so the record can never go backwards, and the first events are written at boot. So the world had already begun at the real present moment, and every backdated item was being pulled forward to meet it.

// Wrong: world begins, then we backdate
world.create()              // t = now
world.append(item, t - 60d) // clamped forward to now

// Right: the clock has to be wrong
// BEFORE the world begins
setClock(now - 60d)
world.create()              // t = 60 days ago
world.append(item)          // and time runs forward
// Wrong: world begins, then we backdate
world.create()              // t = now
world.append(item, t - 60d) // clamped forward to now

// Right: the clock has to be wrong
// BEFORE the world begins
setClock(now - 60d)
world.create()              // t = 60 days ago
world.append(item)          // and time runs forward
// Wrong: world begins, then we backdate
world.create()              // t = now
world.append(item, t - 60d) // clamped forward to now

// Right: the clock has to be wrong
// BEFORE the world begins
setClock(now - 60d)
world.create()              // t = 60 days ago
world.append(item)          // and time runs forward

What made it memorable is how it looked on screen. Sixty-five distinct things, spread across two months, all reporting the same distance from now. And the display was correct. It was faithfully rendering a world in which everything had happened simultaneously.

A calendar-date display would have shown sixty-five identical dates and I would have spotted it in half a second. The elapsed-time display showed sixty-five identical intervals, which read as a rendering quirk rather than a data problem, and cost me an hour.

So even the decision I am defending here has a failure mode, and it is worth naming precisely:

A relative display hides absolute errors. When the reference point is wrong, every value is wrong consistently, and consistency is what our eyes read as correctness.

The general version

Any interface that renders a value relative to a reference point inherits the correctness of that reference and hides its failures.

Percentage change hides the base. A progress bar hides the total. A "compared to last month" hides what last month was. Each of these is more readable than the raw number and each one is a place where a wrong input produces confident, plausible, uniformly incorrect output.

The mitigation is not to abandon relative display. It is to make the reference point visible somewhere, once, for the person who needs to check. In this product that is the detail view, where a thing's exact moment is available if you go and look, and nowhere else.

My father's photograph is dated, on the back, in pencil, in his mother's handwriting. He has never needed it. It is there for whoever comes after, which is exactly the right place for a date to be.

Sources

  • A page from Charles Lyell's notebooks. University of Edinburgh Heritage Collections, CC BY 3.0, via Wikimedia Commons. commons.wikimedia.org/wiki/File:C_Lyell_notebook_page_1.jpg

Related reading

More from the Moc Mallen Studio journal