日期字符串可移植性检查器

粘贴日期或时间戳字符串(也可以是完整日志片段),查看 JS Date、Python 和其他常见解析器会以不同方式读取或拒绝哪些值,以及原因。

在您的浏览器中本地处理。文件绝不会被上传。

使用方法 工具

  1. 粘贴单个日期字符串,或包含日期的较长文本;内容不会离开浏览器。
  2. 选择“检查日期”。
  3. 查看标记值为何有歧义或风险,以及哪些运行环境存在分歧。
  4. 在提供建议时使用 ISO 8601 改写。有些歧义确实无法自动消除;工具会说明原因,而不是猜测。

假设条件

来源与参考数据

方法说明

按形式分类每个类似日期的子串,再检查 JS Date、Python 和严格解析器(包括部分 SQL 引擎)已知的差异:单独日期字符串的隐含 UTC 与本地午夜、无偏移日期时间的本地与 UTC 解释、两位数年份的世纪推断,以及严格解析器拒绝未补零字段。仅当 ISO 8601 改写无歧义时才提供建议,绝不猜测。

计算示例

有歧义的斜线分隔日期

输入项: 01/02/2024

结果: 1 和 2 都是有效月份,因此可能表示 1 月 2 日或 2 月 1 日,取决于采用的惯例。标记为错误,不提供自动改写,因为猜错顺序比保留可见问题更糟。

仅含日期的 ISO 字符串

输入项: 2024-01-15

结果: JavaScript 的 `new Date("2024-01-15")` 解释为 UTC 午夜;其他语言以及 JavaScript 的 `new Date(year, month, day)` 形式则把单独日期解释为本地午夜。在 UTC 以西的时区可能因此落在不同日历日。标记为风险警告;该字符串已经是有效 ISO 8601,不改写。

未补零的日期

输入项: 2024-1-5

结果: JS 和 Python 会宽松接受,但部分严格 SQL 日期解析器会拒绝。安全改写为 2024-01-05。

实用指南
常见错误

常见问题

为什么 01/02/2024 标记为错误,而 25/12/2024 只是提示?

在 01/02/2024 中,1 和 2 都是有效月份,仅凭字符串无法确定顺序。在 25/12/2024 中,25 不可能是月份,因此只能是日/月顺序。它仍不是 ISO 8601,但没有歧义,严重程度较低且可自动改写。

为什么不直接假设两位数年份“24”表示 2024?

很可能是,但根据世纪推断惯例,有些系统会把相同字符串解释为 1924,另一些会解释为 2024。如果错误猜测比不猜更糟,本工具不会静默代用户猜测。

2024-01-15 这样的单独日期字符串真的不安全吗?

风险具体涉及 JS `Date` 与多数其他解析器读取时所表示的时间点:JS 将单独日期视为 UTC,而多数语言视为本地时间。作为纯文本或存储数据完全安全;只有在解析成日期对象并询问它代表哪个时刻时才有风险。

为什么 `new Date('2024-01-15')` 可能显示前一天?

ECMAScript 将仅含日期的 ISO 形式解释为 UTC 午夜。在 UTC 以西的时区,本地显示该时刻时可能落在前一日历日。这不同于构造本地午夜或将值视为无时区日期;本检查器解释基于形式的风险,但不会运行其他运行环境的日期解析器。

上次审核: 2026-09-25

这是基于形式的窄范围扫描器,不是完整日期解析器:只识别五种日期/时间模式,不分析自然语言日期、Unix 时间戳或不常见本地格式。对于真正有歧义的情况,它无法知道原本想表达的日期,只会报告歧义而不自行解决。

主题和工具偏好设置,以及已保存和最近使用的列表仅存储在此浏览器中。