JavaScript Date 构造函数对符合 ISO 8601 标准格式（如 "YYYY-MM-DD"）的字符串统一按 UTC 解析，而对非标准格式（如 "YYYY-M-D"）则依赖实现，通常按本地时区解析，导致相同逻辑下时区偏移不一致。
javascript `date` 构造函数对符合 iso 8601 标准格式（如 `"yyyy-mm-dd"`）的字符串统一按 utc 解析，而对非标准格式（如 `"yyyy-m-d"`）则依赖实现，通常按本地时区解析，导致相同逻辑下时区偏移不一致。
在 JavaScript 中，new Date(dateString) 的行为并非完全一致——其解析逻辑严格取决于输入字符串是否符合 ECMAScript 规范定义的 Date Time String Format（即简化版 ISO 8601 格式）。该格式要求年、月、日必须为固定宽度："YYYY-MM-DD"（月和日需补零），且隐含时区为 UTC。
✅ 符合标准格式 → 统一按 UTC 解析
console.log(new Date("2023-12-16")); // => 2023-12-16T00:00:00.000Z（UTC 零点）
console.log(new Date("2023-09-14")); // => 2023-09-14T00:00:00.000Z（UTC 零点）❌ 不符合标准格式 → 进入实现依赖模式（通常按本地时区解析）
console.log(new Date("2023-1-1")); // → "2023-01-01T07:00:00.000Z"（示例中本地为 UTC-7）
console.log(new Date("2023-9-14")); // → "2023-09-14T06:00:00.000Z"（夏季 DST，UTC-6）注意："2023-1-1" 和 "2023-9-14" 因缺少前导零（M/D 为单数字），不满足 MM/DD 要求，被判定为“非标准”，从而触发浏览器/运行时的启发式解析（如 V8 在 Chrome/Node.js/Office Scripts 中默认按本地时区解释为 00:00，再转换为 UTC 时间戳）。
立即学习“Java免费学习笔记（深入）”；
? 关键结论：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 时区差异不是“未来 vs 过去”的问题，而是“格式合规性”问题；
-
"2023-12-16"合规 → UTC；"2023-1-1"不合规 → 本地时区 → 转 UTC 后出现偏移； - 同样，
"2023-9-14"（不合规）与"2023-09-14"（合规）输出不同，正是此机制的直接体现。
✅ 正确实践（保障跨环境一致性）：
始终使用零填充格式：
"YYYY-MM-DD"；-
如需明确本地时区语义，显式构造：
// 安全：明确以本地时区解析 const localDate = new Date(2023, 0, 1); // 注意：month 是 0-indexed！ // 或从字符串安全转换（推荐） function parseLocalDate(str) { const [y, m, d] = str.split('-').map(Number); return new Date(y, m - 1, d); // 自动按本地时区 } console.log(parseLocalDate("2023-1-1")); // 2023-01-01T00:00:00.000（本地时区）
⚠️ 注意事项：
- Office Scripts 运行于 Azure Functions 环境，默认时区为 UTC，但
Date构造函数仍遵循 ECMAScript 规范，不改变解析逻辑； - 避免依赖
new Date("Y-M-D")，它在 Safari、Firefox、Node.js 中行为可能略有差异； - 生产代码中，优先使用
Intl.DateTimeFormat、date-fns或dayjs等库处理复杂场景，而非原生字符串解析。
总之，统一格式是规避时区陷阱最简单、最可靠的方式：永远用 "2023-01-01"，而不是 "2023-1-1"。
