History must keep original timestamps, not reorder by time of viewing

What it is

Times in history should be when the event happened (produced or delivered), not when someone opened history, tapped the row, or the device finally came online. Reordering by view time paints a 15:00 alert as if it just happened at 21:00 and rewrites cause: people infer "who spoke first" and "is this the one from just now" on the wrong sequence.

This is the clock inside history. It is not whether items belong in history, and not how items held during do not disturb are merged in.

Why it happens

Time is the anchor for reconstructing situation: a meeting then, sleep then, whether the order had already shipped. Wrong anchors scramble both recall and blame. Systems have many times—produced, queued, delivered, shown, read—and if the default display takes read time or "opened history," the list reshuffles on every view and yesterday's sequence becomes "all just now." What is lost is not seconds of precision but order among events.

Offline catch-up is where the wrong clock shows most: on open, the backlog is stamped "now" and looks like a fresh bombardment that was actually daytime work. Keep the original event time; if needed, mark "delivered just now" as a secondary.

Studying it

Build a known order (including offline catch-up) and compare lists sorted by event time versus by opening history. Ask which happened first and whether that one is "from just now."

Independent variables: sort key (event / shown / read), whether catch-up restamps, whether display is localized. Dependent variables: order accuracy, share of old events read as new arrivals, misattribution (thinking someone sent just now).

Lab clocks are synced and will not show catch-up. Drop the network on purpose. "The list feels fresh" is not a good experience—it may be the illusion reordering creates.

Where it stops holding

Relative labels ("just now / 5 min ago") can assist, but the sort key must remain absolute event time or refresh will jump the order. Cross-zone viewing should show local-at-the-time, and sender zone when it matters, so "they sent at night" is not read as "this afternoon on my clock." Manually marking unread must not rewrite the time to now; that is state, not a new event.

Applying it

• History rows show event time (local) and sort stably by it; a new view does not reshuffle.
• Offline catch-up keeps the original stamp; a secondary mark may say delivery was delayed, without overwriting.
• Relative time is display-only; a tap or a later day should reveal clock time.
• Verify with A in the morning, B in the afternoon, history opened at night. A should still precede B with a morning stamp. If both become "just now" or B precedes A, the clock is wrong. Repeat after an offline catch-up.

Related

• Within the group: H5.11.1 Dismissed notices must be replayable in history · H5.11.3 Items held during do not disturb must merge into history, not vanish · H5.11.4 Missing history drives repeated checking for updates
• Adjacent: H5.04 Notification bundling · H8.06 Version history · H5.07 Push frequency
• Search terms: event time · access time · notification timestamp