After the user changes zone, past records must keep the same absolute instant

What it is

Someone flies Beijing to London, or flips the zone in settings, and “now” on the watch changes. Past records already stored must not change the instant they name. That message is still the moment it was sent; that order is still the moment it filled. The clock face may be redrawn in the new local (Beijing 23:00 drawn as London 16:00). It must not be rewritten as “London 23:00” — that is a different instant. What time it is for the other person is collaboration presentation. This is only whether, after one’s own zone change, historical coordinates are still there.

Why it happens

If a past record stores an instant, a zone change only changes the projection: same instant, new local face. If it stores an unzoned local numeral, the change offers a wrong temptation — keep showing “15:00” as 15:00, which translates the instant by eight hours. People will think a message they sent at three in the afternoon was sent at three in the afternoon in London; timelines, ledgers, deadlines all shift. The correct zone change is: history keeps the instant and redraws the face; “now”, and futures still understood as a local clock face, follow the new zone.

Someone may want “the clock face I see not to change”. That is a request to freeze the projection, not to let the instant fly with them. If a product offers “always view history on this city’s clock”, that is a fixed presentation zone, still aimed at the original instant, not a rewrite of the record.

Where it stops holding

A future reminder understood as “my local ten”, not yet occurred, should usually move to ten in the new local after a zone change; otherwise people are woken at dawn in the new zone. That is a future rule, not a past record. An in-flight countdown bound to an absolute end instant only changes its face; remaining seconds stay. One bound to “today 18:00 local” changes the end instant on a zone change, and must ask whether to move it. Logs exported for audit sometimes need the presentation zone locked at export, so a recipient does not project again and talk past the numbers; what is locked is the drawing, not a rewritten instant.

Applying it

• Historical messages, orders, completed events: after a zone change, redraw the face; keep the instant. Do not display an unzoned “15:00” unchanged in the new zone.
• If “view history on a fixed city’s clock” is offered, what is fixed is the presentation zone; the record remains an instant.
• Treat future local-face rules and past instants as different code paths. Do not run both through one “follow settings” function.
• How to check: note a historical record’s instant and the face then. Change the device zone and open it again; the face should be the new zone’s projection, and converting back to UTC should yield the same instant. If the face numerals are unchanged, the instant was translated — fail. Contrast with a future “every day at 7:00 local” alarm: after the zone change it should ask, or move to 7:00 in the new local, and must not share the history path.

Related

• Same group: I4.08.1 Store time in an absolute standard; convert to local only at display · I4.08.2 Recurring events that cross DST must recompute local clock time, not a fixed offset · I4.08.3 Time-zone rules change with politics; year-spanning conversion cannot assume a frozen map
• Nearby: I4.05 Time zones · I3.06 State persistence
• Search terms: timezone change · preserve instant · rebasing local time