JavaScript 的 Date Parser 已失控，需要停止

Source: Dev.to

日期字符串解析不一致

JavaScript 的 Date 构造函数旨在保持灵活，但这种灵活性常常导致不可预测的行为。虽然它声称会按照 ISO 8601 标准解析日期字符串，但当输入不是有效的 ISO 字符串时，它会退回到浏览器特定的实现。这种不一致已经困扰开发者数十年，导致从金融系统到面向用户的表单等各种应用出现 bug。

// example.js
const date1 = new Date('2024-03-10');
const date2 = new Date('10/03/2024');

console.log(date1); // 有效的 ISO 8601，按预期解析
console.log(date2); // 区域依赖：Chrome → MM/DD/YYYY，Firefox → DD/MM/YYYY

在一个地区能够正确解析的日期字符串在另一个地区会悄然失效，造成用户体验噩梦。

即使是 ISO 8601，部分日期的处理在各浏览器之间也不一致：

const isoDate = new Date('2024-03-10');
console.log(isoDate.toString());
// Chrome: "Sun Mar 10 2024 00:00:00 GMT-0600 (Central Standard Time)"
// Firefox: "Sun Mar 10 2024 00:00:00 GMT-0600 (CST)"

规范将 YYYY‑MM‑DD 视为 UTC 日期，但某些浏览器将其解释为本地时间，导致期望确定性行为的应用出现问题。

时区和夏令时陷阱

Date 对象依赖系统时区，这会加剧问题。在夏令时（DST）切换期间添加天数可能产生错误的结果：

const date = new Date('2024-03-10T02:00:00Z');
date.setDate(date.getDate() + 7);
console.log(date.toISOString());
// 可能输出 "2024-03-17T03:00:00Z"，因为 DST 偏移

开发者必须手动处理时区偏移，这既容易出错又受地区影响。

新兴解决方案

JavaScript 生态正在演进，以解决这些问题：

• Luxon – 一个功能强大的库，用于在显式时区支持下解析和格式化日期。
• date-fns – 一个轻量级的实用库，用于不可变的日期操作。
• Temporal API（Stage 4 提案）– Date 的标准化替代方案，提供对时间的精确控制。

示例：使用 Luxon 进行确定性解析

// luxon-example.js
import { DateTime } from 'luxon';

const luxonDate = DateTime.fromISO('2024-03-10', { zone: 'UTC' });
console.log(luxonDate.toJSDate()); // 始终表示 2024-03-10T00:00:00Z

可靠日期处理的最佳实践

1. 验证输入 – 使用严格的正则表达式或验证库（例如 Yup）。
2. 以 UTC 存储和传输 – 避免跨系统的时区漂移。
3. 采用现代库 – Luxon、date-fns 或即将推出的 Temporal API。

通过采纳这些实践，我们可以终结混乱，构建在浏览器和地区之间表现一致的应用。