不带时区，仅返回本地时区的 YYYY-MM-DD 字符串；跨时区需在 JS 层明确用户意图（本地午夜或 UTC 零点），配合语义标记与 IANA 时区库处理。
HTML5 的 本身不处理时区，它只认本地时区的年月日，且始终以 YYYY-MM-DD 格式提交 —— 这个字符串没有时区信息，也不代表某个具体时间点。所谓“跨时区处理”，实际是你在 JS 层面对用户输入、显示、存储和传输环节做主动控制。
为什么
HTML5 规范明确要求该控件的值是“本地时区的日期”，不包含小时分钟秒，也不绑定 UTC 或任意时区。浏览器内部用的是宿主系统时区解析这个值，比如用户在北京选了 2024-06-15，控件返回的就是字符串 "2024-06-15"，不是 Date 对象，更不是 2024-06-15T00:00:00+08:00。
- 你无法通过
valueAsDate获取带时区的Date对象（它会按本地时区解释为当天 00:00） - 提交表单时，后端收到的只是纯字符串，时区含义完全丢失
- 不同地区用户选同一个
2024-06-15，对应的真实 UTC 时间可能差一整天
如何把用户选的日期转成指定时区的 UTC 时间点？
关键在于：你要明确“用户意图”。比如用户在上海选了 2024-06-15，你是想表达“上海当地时间 6 月 15 日 00:00”还是“全球统一的 6 月 15 日”？前者需转成 2024-06-14T16:00:00Z（UTC），后者应转成 2024-06-15T00:00:00Z（强制对齐 UTC 零点）。
- 若业务语义是“某地生效日”，用
toLocaleString('en', {timeZone: 'Asia/Shanghai'})构造本地午夜再转 UTC - 若语义是“全球统一日历日”，直接拼接
2024-06-15T00:00:00Z，不依赖用户时区 - 避免用
new Date('2024-06-15')—— 它在 Safari 和 Chrome 行为不一致（Safari 当作 UTC，Chrome 当作本地）
推荐做法：
立即学习“前端免费学习笔记（深入）”；
function dateStrToUtcMidnight(dateStr, timeZone = 'UTC') {
const [y, m, d] = dateStr.split('-');
const dt = new Date(Date.UTC(y, m - 1, d));
return dt.toISOString().slice(0, 10) + 'T00:00:00Z';
}后端接收时怎么避免歧义？
不要直接信任前端传来的 2024-06-15 字符串。必须配合额外字段说明语义：
- 加一个
date_semantics字段，值为"local"或"utc" - 或约定所有日期字符串都按 UTC 零点解释（最简单，但 UI 上要提示用户“以 UTC 时间为准”）
- 如果业务强依赖时区（如航班起飞日），前端应主动传
timeZone（如Asia/Shanghai），后端用 IANA 时区库解析
常见错误：new Date(input.value).toISOString() —— 这会把本地时区的午夜当成 UTC 时间，导致偏移 8 小时（东八区）甚至更多。
显示时怎么让不同时区用户看到一致的日期？
不能靠 自动适配。你需要：
- 后端返回 ISO 日期字符串（如
"2024-06-15"）并附带语义标记 - 前端用
Intl.DateTimeFormat按用户本地时区格式化显示（仅用于展示） - 编辑时仍用原字符串初始化
input，不转换 —— 否则用户修改后可能跳变一天
例如用户在纽约看 "2024-06-15"（UTC），应显示为 “June 14, 2024”（因为 UTC 6.15 00:00 是 EDT 6.14 20:00），但输入框里仍填 2024-06-15，保持数据源统一。
真正麻烦的不是转换代码，而是业务规则是否清晰：这个日期到底锚定在哪条时间线？没想清楚这点，任何时区处理都是空中楼阁。
