JavaScript Date 按年月日创建：本地零点与 UTC 零点为什么不是同一刻
页面选择十月一日，保存成 ISO 字符串后却显示九月三十日，这不一定意味着数据丢了一天。一个年月日可以表达当地日历中的日期，而 Date 需要表示时间轴上的一个时刻。把当地零点换成 UTC 表示，日期部分完全可能落在前一天。
首先明确业务要存的是什么。生日、排班日期和账期标签往往只需要年月日；实际发生的提交时间则需要确定的时刻。如果一开始只拿到日期，却随手补成本地零点再取 UTC 字符串，就已经额外引入了时区解释，后面的字符串截取无法消除它。
AI概念配图：用抽象物件说明本文讨论的关系，不是实际运行界面或测量结果。
用固定时区复现实验，避免依赖电脑设置
下面代码保存为 demo.cjs，用 Node.js 运行。父进程分别启动 UTC 与上海时区的子进程，并把 TZ 明确放进环境变量。实验采用固定日期，不读取当前时间，不使用季节切换附近的特殊时刻，因此每次执行都能比较相同的预期结果。
多参数 Date 构造把年月日解释成本地时间；Date.UTC 把相同分量解释成 UTC，并返回毫秒时间值，再交给 Date 创建对象。两者看起来都填了同一个年月日，在上海时区却相差八小时。代码同时检查时间值与输出，避免只观察格式。
const assert = require('node:assert/strict');
const { execFileSync } = require('node:child_process');
const probe = `
const local = new Date(2026, 9, 1);
const utc = new Date(Date.UTC(2026, 9, 1));
console.log(JSON.stringify({
localISO: local.toISOString(), utcISO: utc.toISOString(),
localDay: local.getDate(), utcDay: local.getUTCDate(),
month: local.getMonth(), difference: utc.getTime() - local.getTime()
}));`;
function run(tz) {
return JSON.parse(execFileSync(process.execPath, ['-e', probe], {
env: { ...process.env, TZ: tz }, encoding: 'utf8'
}));
}
const z = run('Etc/UTC');
const s = run('Asia/Shanghai');
assert.equal(z.localISO, '2026-10-01T00:00:00.000Z');
assert.equal(s.localISO, '2026-09-30T16:00:00.000Z');
assert.equal(s.utcISO, z.utcISO);
assert.equal(s.utcISO, '2026-10-01T00:00:00.000Z');
assert.equal(s.localDay, 1);
assert.equal(s.utcDay, 30);
assert.equal(s.month, 9);
assert.equal(z.difference, 0);
assert.equal(s.difference, 8 * 60 * 60 * 1000);
console.log('UTC local midnight:', z.localISO);
console.log('Shanghai local midnight:', s.localISO);
function validDate(y, m, d) {
if (![y, m, d].every(Number.isInteger) || y < 100 || y > 9999) return false;
const x = new Date(Date.UTC(y, m - 1, d));
return x.getUTCFullYear() === y && x.getUTCMonth() === m - 1 && x.getUTCDate() === d;
}
assert.equal(validDate(2024, 2, 29), true);
assert.equal(validDate(2026, 2, 29), false);
assert.equal(validDate(2026, 2, 31), false);
assert.equal(validDate(2026, 13, 1), false);
assert.equal(validDate(26, 10, 1), false);
assert.equal(validDate(2026, 10, 0), false);
assert.equal(validDate(2026, 10, 1.5), false);
console.log('component, range and calendar-validation checks passed');读取分量时也要选择同一套坐标
本地读取方法与 UTC 读取方法回答不同问题。上海零点对应前一天的 UTC 下午，因此它的 getDate 是一，而 getUTCDate 是三十。程序还检查月份从零开始：传入九代表十月；如果忘了这条规则，偏差会比时区造成的跨日更大。
toISOString 输出的是 UTC 表示，因此取它前十个字符得到的是 UTC 日期，不能普遍用来提取本地日历日期。若目标是显示本地日期，应在选定的时区下读取或格式化；若目标是保存纯日期，可以保留经过校验的年月日字段或日期字符串。
不要在已经按本地时间解释之后，再机械加减一次时区偏移来“修复”。在一个时区看似正确的补丁，换个运行环境可能重复转换。更可靠的方法是从输入语义出发，明确每次构造与读取分别采用本地分量还是 UTC 分量。
日期构造成功，不等于输入日期有效
Date 会把越界的分量进行归一化，例如非闰年的二月三十一日会进位到三月。代码为 UTC 日历字段建立一个小校验函数：构造之后读取年月日，再与输入逐个比较。只有相等才接受，从而把方便的自动进位与严格输入检查区分开来。
多参数构造与 Date.UTC 对零到九十九的年份还存在映射到二十世纪的历史规则。这里的校验函数明确只接收一百到九千九百九十九的整数年份，并把这个范围写进断言，避免教程代码无意承诺支持所有历史日期。
这个实验验证了两种时区下的构造语义，并不解决所有地区的夏令时、历史偏移或本地不存在时间。真实系统如果允许用户指定地区，时区标识与日期应一起进入设计；不要根据本机当前偏移推算另一个日期的偏移。
回归测试可以保留同一日期在两种时区的 ISO 输出、本地与 UTC 跨日结果、月份边界、闰日和越界日期。确认这些之后，再检查业务接口究竟交换纯日期还是毫秒时间值，能比反复修改页面显示格式更早定位问题。
