日期去重实战:把不同写法的同一天合成一条

整理一堆日期的时候,最坑的不是日期多,而是同一天被写成好几种样子。运营导出的表里写 2026/1/5,开发的日志里写 2026-01-05,工单系统又给你一个 2026-01-05T00:00:00Z。眼睛一看都是一月五号,可只要你拿去做普通的文本去重,这三条会被当成三个不同的值留下来,统计独立日期立刻多算两天。

ISO 日期去重工具就是为这个场景做的:先把每个日期规范化成统一格式,再按规范化结果去重复日期,而不是按原始字符串去比。

为什么普通去重认不出同一天

文本去重的逻辑很简单,字符串相等就算重复。问题在于日期有太多合法写法:斜杠和连字符,有没有前导零(1 和 01),带不带时间和时区。2026/1/5 和 2026-01-05 一个字符都不一样,在字符串层面是两个完全不同的值,去重当然留两条。

人能看出它们是同一天,是因为我们在脑子里做了一次"归一化",把写法的差异抹掉只看语义。机器要做到这一点,就得先把这一步显式化:把所有日期解析成同一个标准结构,再来比较。

规范化成 ISO 格式后再比较

具体做法是,把每个日期都解析成 ISO 8601 标准形式(YYYY-MM-DD,带时间的还会补上时分秒和时区),然后用这个规范化后的结果当作去重的判断依据。

这一步解决了三类差异:

分隔符差异:2026/1/5,2026.1.5,2026-01-05 解析后都是 2026-01-05。
前导零差异:1 月和 01 月归一化后完全一致。
同一时刻的不同时区写法:2024-03-01T12:00:00Z 和 2024-03-01T12:00:00+00:00 指向同一瞬间,会折叠成一条,保留首次出现的那个。

去重的钥匙是规范化后的值,不是你原来敲进去的那串字符。所以哪怕来源格式五花八门,只要它们表示的是同一天(或同一时刻),就会被合并成一行,并附上重复次数和首次出现的行号,方便你回头解释这条数据是从哪几份导出里合过来的。

一个真实的输入输出例子

把下面这段贴进去:

工具会先把每行规范化,发现前三行其实都是 2026-01-05,于是合并成一条,重复次数标 3,首次出现在第 1 行;最后一行 2025-12-31 单独保留。输出只剩两行干净结果:

2026-01-05   (出现 3 次,首见第 1 行)
2025-12-31   (出现 1 次,首见第 4 行)

2026/1/5 和 2026-01-05 被算成一个,这正是普通去重做不到、而这里默认就会做的事。

整理时间线,统计独立日期,清理日志

我自己最常用它来收尾几类活:

合并多份导出。两个运营各导一份名单,日期写法不统一,合在一起想知道一共覆盖了多少个不同的日子。去重后看输出行数,就是真正的独立日期数。

整理时间线。从一段日志或复制的网页里把日期抓出来,规范化排序后,事件发生的先后一目了然,重复打点的也不会让时间轴看起来比实际更密。

清理日志。日志里同一个动作可能被记了很多次,先把时间戳去重,再看剩下多少个独立时点,排查问题时不至于被重复行带偏。

如果你只想纯粹做格式统一而不去重,可以先用 ISO 日期规范化工具把写法拉齐,再回到 ISO 日期去重工具做合并。两步拆开,中间结果也能复核。

本地处理,数据不出浏览器

日期看着不敏感,但它常常贴在客户记录,工单,内部日志旁边。这个工具的解析,校验,规范化,去重,复制和下载全部在浏览器本地完成,上传的文本文件用 File API 在当前标签页读取,没有任何时间戳会发到服务器。

需要留审计线索时,别只复制最终列表,顺手下载带行号的 CSV 或 Markdown,这样每条去重结果都能追回它的来源行。另外提醒一句:日期校验只验格式,格式对不代表那条记录背后的账号或资源真实存在,这是两回事。

整理时间线,统计独立日期,清理日志,本质上都是同一件事:先把"长得不一样的同一天"认出来。规范化成 ISO 格式再比较,就是认出来的可靠办法。

Made by Toolora · Updated 2026-06-13