把一批关于同一事件的报道按发布时间从早到晚排列，看起来是最直接、最"客观"的还原事件经过的方法——毕竟发布时间是系统里最容易拿到、也最不会出错的字段。但这里最容易忽略的一点是：发布时间只是报道被公开的时间，不是事情实际发生的时间，两者之间的间隔可能是几分钟，也可能是几天甚至更久，一旦把发布顺序当成事情发生的顺序，整条事件经过很容易被排错。
举一个示意场景：假设某地在周一发生了一起设施故障（这是事件实际发生的时间，Occurred Time）。当地小范围社交媒体在周一当天就有零星讨论，但没有被主流媒体注意到；一家区域媒体在周三补发了详细报道（这是该条报道的发布时间，Published Time）；随后官方在周五发布了处理结果的正式通报，通报中说明相关整改措施自周六起生效（这是生效时间，Effective Time）。如果系统只按发布时间排序，会得到"周三报道故障、周五通报处理、周六整改"这样一条看似合理的时间线；但真正应该先找的是事件本身的发生时间——故障其实周一就已经发生，中间存在两天多的报道滞后，这个滞后本身可能正是需要关注的信息，比如"为什么故障发生后两天才有媒体报道"，而这条线索在只看发布时间的排序里完全被掩盖了。
三个不能合并成一个的时间字段
第一眼看，"什么时候报道的"和"什么时候发生的"似乎没必要分得那么细，反正最后都能拼出一条时间线。但在系统层面，至少需要区分以下三类时间字段，否则聚类和排序都会出问题：
- Occurred Time（发生时间）：事件在现实世界中实际发生或开始的时间，通常需要从报道内容里提取，而不是直接读取系统时间戳；
- Published Time（发布时间）：某一篇具体报道对外公开的时间，反映的是信息传播节奏，而不是事件本身的节奏；
- Effective Time（生效时间）：某项决定、政策或整改措施正式产生效力的时间，可能晚于事件发生时间很久，也可能晚于相关报道发布很久。
把三类时间字段落到具体记录里是什么样子
| 记录对象 | Occurred 发生时间 | Published 发布时间 | Effective 生效时间 |
|---|---|---|---|
| 设施故障本身 | 周一 | 周三（首次详细报道） | 不适用 |
| 官方处理通报 | 周五（通报中确认的处理决定） | 周五 | 周六 |
| 年度报告中的回顾条目 | 周一（仍指向同一起故障） | 次年（报告发布时间） | 不适用 |
把这三条记录并排放在一起才能看清楚：年度报告的发布时间虽然晚了将近一年，但它的Occurred Time字段仍然锚定在最初的周一，这样系统才不会把"一年后被重新提起"误判成"一年后又发生了一次"。这也是为什么仅仅记录一个"时间"字段是不够的——一个字段承担不了区分"什么时候发生"和"什么时候被再次提起"这两种完全不同信息的任务，尚未确认具体细节的报道更需要这种区分，否则连基本的先后顺序都可能搞错。反过来说，如果分析师只拿到一份不带字段说明的时间戳列表，第一步该做的也不是直接排序，而是先问一句：这个时间戳记录的到底是哪一类时间，会不会有人已经默默把三种含义混在同一列数据里了。
把这三类时间分别记录之后，还需要处理一种更隐蔽的情况：同一事件在传播过程中被多次"重新报道"。比如故障发生一个月后，某机构发布年度报告时又提到了这起事件作为案例——这篇报告的发布时间很晚，但它讨论的仍然是同一个Occurred Time对应的历史事件，不应该被误判为"又发生了一次新故障"。鼎天国际事件在处理时间线时，会优先锚定Occurred Time作为事件排序的主轴，把Published Time和Effective Time作为附加维度分别标注，这样即使某条报道的发布时间很晚，系统也能正确判断它谈论的是哪一个历史节点，而不会把旧事件误认成新事件反复计入统计。
