Safari 日期解析踩坑：不要把非标准 YYYY-MM-DD HH:mm:ss 交给 Date.parse

一、问题概述：非标准 Date.parse 输入没有跨引擎承诺

ECMAScript 只为规定的日期时间字符串格式提供可移植语义；对于 2026-07-28 12:00:00 或 2026/07/28 这类输入，实现可以采用自己的回退解析。某个 Chrome 版本能解析，不代表 Safari、Firefox、Node.js 或未来版本会得到相同结果。

二、最小复现：不同日期字符串在 Safari 中的报错解析

下面的对比示范了各种常见日期格式在 Safari 中的解析差异与崩溃场景：

/* 场景 1：非标准空格分隔符字符串 "YYYY-MM-DD HH:mm:ss" */
const str1 = "2026-07-28 12:00:00";
// Chrome V8: 解析正常 -> Tue Jul 28 2026 12:00:00 GMT+0800
// Safari JSC: 解析失败 -> Invalid Date (NaN)!

/* 场景 2：标准 ISO 8601 格式 "YYYY-MM-DDTHH:mm:ss" (使用 'T' 分隔) */
const str2 = "2026-07-28T12:00:00Z";
// Chrome & Safari: 解析均正常 -> 2026-07-28T12:00:00.000Z

/* 场景 3：仅日期 "YYYY-MM-DD" */
// 注意：ISO 8601 中 "YYYY-MM-DD" 会被默认解析为 UTC 时间 00:00:00，而非本地时间！

三、根因分析：ECMAScript 标准格式与实现定义的回退解析

1. 标准输入：可移植的时间点应使用 T 分隔并带 Z 或显式偏移量。2. 非标准回退：空格、斜杠和省略字段如何解析可能随引擎与版本变化，不能把某次测试结果写成永久兼容性保证。3. UTC vs Local：标准 date-only YYYY-MM-DD 按 UTC 解释；带时间但无偏移量的标准形式表示本地时间，这两种语义混用会造成跨时区日期偏移。

四、推荐方案：分开处理绝对时间点与本地墙上时间

1. 绝对时间点：要求后端输出带 Z 或明确偏移量的 ISO 8601 字符串，例如 2026-07-28T12:00:00+08:00。2. 本地墙上时间：若字段明确代表用户所在地区的本地时间，按约定格式拆分组件，再用 new Date(year, monthIndex, ...) 构造。3. 不做猜测性替换：把空格替换成 T 并不会自动补出时区，把连字符换成斜杠更不是跨浏览器标准。

五、完整代码：严格区分 ISO 时间点与本地日期时间

下面的解析器只接受三种明确输入：带时区 ISO 时间点、标准 date-only（按规范视为 UTC），以及严格的本地 YYYY-MM-DD HH:mm:ss。组件构造后还会反向校验，拒绝被 Date 自动滚动成下个月的 2026-02-31。

function parseKnownDateFormat(input: string): Date {
  const value = input.trim();
  const instant = /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d{1,3})?(?:Z|[+-]\d{2}:\d{2})$/;
  const dateOnly = /^\d{4}-\d{2}-\d{2}$/;

  if (instant.test(value) || dateOnly.test(value)) {
    const date = new Date(value);
    if (Number.isNaN(date.getTime())) throw new RangeError("无效的 ISO 日期");
    return date;
  }

  const local = /^(\d{4})-(\d{2})-(\d{2})[ T](\d{2}):(\d{2})(?::(\d{2}))?$/.exec(value);
  if (!local) throw new TypeError("不支持的日期格式");

  const [, y, m, d, hh, mm, ss = "0"] = local;
  const parts = [y, m, d, hh, mm, ss].map(Number);
  const [year, month, day, hour, minute, second] = parts;
  const date = new Date(year, month - 1, day, hour, minute, second);

  if (date.getFullYear() !== year || date.getMonth() !== month - 1
      || date.getDate() !== day || date.getHours() !== hour
      || date.getMinutes() !== minute || date.getSeconds() !== second) {
    throw new RangeError("本地日期组件越界");
  }
  return date;
}

console.log(parseKnownDateFormat("2026-07-28T12:00:00+08:00").toISOString());
console.log(parseKnownDateFormat("2026-07-28 12:00:00").toString());

六、常见错误方案

使用简单的全局 dateStr.replace(/-/g, '/') 处理包含 ISO 'T' 和 'Z' 的复合字符串导致路径破坏；直接使用非标准的日期格式在生产环境发布。

七、边界条件：仅日期 YYYY-MM-DD 的时区偏移偏差陷阱

在东八区 (UTC+8) 中，new Date('2026-07-28') 解析为 UTC 0 点，格式化为本地时间会变成 2026-07-28 08:00:00；而在西五区 (UTC-5) 中则会变成 2026-07-27 19:00:00（日期倒退了一天！）。处理仅日期字符串时建议显式追加本地时间或组件解析。

八、如何验证 Safari 兼容性

在 Safari、Chrome、Firefox 与服务端运行时执行同一组测试向量，覆盖闰年、无效日期、DST 切换、本地时间、Z 和正负偏移量。断言精确毫秒值或明确异常，不能只断言结果不是 Invalid Date。

九、FAQ

问：为什么某个浏览器能解析空格日期？答：那属于实现自带的非标准回退行为，不能作为接口契约。

问：使用日期库就一定安全吗？答：只有在调用明确的格式解析 API 并启用严格模式时才可靠；若库最终仍把未知字符串交给原生 Date，问题依旧存在。

问：后端应该输出什么？答：绝对时间点输出带 Z 或偏移量的 ISO 字符串，或明确单位的 Unix 时间戳；纯日期字段则保持 date-only 类型，不要伪装成时间点。

十、总结

问题不在 Safari“太严格”，而在应用把非标准字符串交给了实现定义的解析器。用带时区 ISO 表达时间点，用严格组件解析表达本地墙上时间，并对越界日期做反向校验，才能获得稳定语义。