H5.11.2history keeps original timestamps设计研究
历史记录需要保留原始时间而非按查看时间重新排序
别名: 原始时间戳 · 不要按打开时间排 · event time vs access time
概念解释
历史列表里的时间应是事件发生的时间（送达或产生），不是人打开历史、点开条目、或设备终于联网的时间。按查看时间重排，会把下午三点的告警显示成晚上九点刚发生，因果被改写：人会用错误的先后去推断「谁先说的」「这是不是刚才那次」。
这条只谈历史里的时钟。它不讨论条目要不要进历史，也不讨论免打扰期间被压住的东西如何并进来。
机制
时间是重建情境的锚：当时在开会、当时已经睡了、当时订单是否已发出。锚一错，回忆和责任判断一起错。系统有多种时间可用——产生、入队、送达、展示、阅读——默认展示若取了阅读或打开历史的时刻，列表会在每次查看时重洗，昨天的序列变成「全是刚刚」。人失去的不是精确到秒，而是事件之间的顺序。
离线补发特别容易用错时钟：一打开，积压全盖上「现在」，看起来像一次新的轰炸，其实是白天的事。正确的做法是保留原事件时间，需要的话另标「刚刚送达」。
怎么研究
构造已知顺序的事件（含离线补发），比较列表按事件时间排与按打开历史时间排。让人回答「哪件先发生」「那件是不是刚才」。
自变量：排序键（事件 / 展示 / 阅读）、离线补发是否改戳、时区显示是否本地化。 因变量：顺序判断正确率、把旧事件当成新到达的比例、错误归因（以为某人刚刚才发）。
实验室时钟同步，测不到补发。要特意断网再恢复。不要用「觉得列表很新」当体验好——那可能正是重排造成的错觉。
边界
「刚刚 / 5 分钟前」这种相对时间可以作辅助，但排序键仍应是绝对事件时间，否则刷新页面顺序会跳。跨时区查看应显示当地当时，并在必要时标出发送方时区，避免把「对方夜里发的」读成「我这边下午发的」。用户手动「标为未读」不应把时间改成现在；那是状态，不是新事件。
怎么落地
- 历史行显示事件时间（本地），排序稳定按该时间，新查看不重洗。
- 离线补发保留原戳，可用次要标记表示送达延迟，不要覆盖原戳。
- 相对时间只作展示层，点开或隔日后应能看到钟面时间。
- 验证：上午发 A、下午发 B，晚上第一次打开历史。A 应仍在 B 之前且时间仍是上午。若两条都变成「刚刚」或 B 在 A 前，时钟就用错了。断网补一遍同样的检查。