HTML date 选对了日期却显示前一天：先区分日历日期与时间点

表单里选的是10月23日，保存后在另一个时区显示成10月22日。日期控件没有偷偷改值，代码把一个业务日期转换成了时间点，再按当地时区显示，含义已经变了。

生日、账期和酒店入住日期，常常只表达日历上的某一天；会议开始时间则通常需要一个确定时间点。两者都能写成与日期有关的字符串，却不能因此共享同一种Date转换流程。

HTML的date输入值适合传递一份规范日历日期。界面可以按用户地区显示，value仍使用规定格式。问题经常发生在拿到value以后，为了“统一时间格式”执行new Date，再把结果送进通用时间显示组件。

一页同时看到原日期与两个时区视图

保存为 date-contract.html，在现代浏览器打开。页面不发网络请求；提交时只展示准备发送的字段。

<!doctype html>
<html lang="zh-CN">
<meta charset="utf-8">
<title>业务日期与时间点</title>
<style>
body { max-width: 48rem; margin: 2rem auto; padding: 1rem; font: 16px sans-serif; }
pre { white-space: pre-wrap; padding: 1rem; background: #eef3f8; }
</style>
<form id="form">
  <label for="day">业务日期</label>
  <input id="day" name="day" type="date" value="2026-10-23"
    required min="2026-01-01" max="2026-12-31">
  <button type="submit">检查并准备提交</button>
</form>
<button id="inspect" type="button">查看当前值与约束</button>
<pre id="report" role="status"></pre>
<pre id="payload"></pre>
<script>
const day = document.querySelector('#day');
function calendarInZone(instant, timeZone) {
  const parts = new Intl.DateTimeFormat('en-US', {
    timeZone, year: 'numeric', month: '2-digit', day: '2-digit'
  }).formatToParts(instant);
  const get = type => parts.find(part => part.type === type).value;
  return `${get('year')}-${get('month')}-${get('day')}`;
}
function inspect() {
  const lines = [
    `input.value=${JSON.stringify(day.value)}`,
    `合法=${day.validity.valid}；缺失=${day.validity.valueMissing}；超上限=${day.validity.rangeOverflow}`
  ];
  if (day.value) {
    const instant = new Date(day.value);
    lines.push(`转换成 Date 后的 ISO：${instant.toISOString()}`);
    lines.push(`同一时间点在洛杉矶：${calendarInZone(instant, 'America/Los_Angeles')}`);
    lines.push(`同一时间点在上海：${calendarInZone(instant, 'Asia/Shanghai')}`);
  }
  document.querySelector('#report').textContent = lines.join('\n');
}
document.querySelector('#form').addEventListener('submit', event => {
  event.preventDefault();
  const data = Object.fromEntries(new FormData(event.currentTarget));
  document.querySelector('#payload').textContent = JSON.stringify(data);
  inspect();
});
day.addEventListener('input', inspect);
document.querySelector('#inspect').addEventListener('click', inspect);
inspect();
</script>
</html>

默认值仍然是2026-10-23。把这个字符串交给Date构造后，对应的ISO时间是UTC的当天零点；按洛杉矶时区显示这个时间点时，日期落在前一天。这里显式指定两个时区，因此不用修改电脑系统设置就能重现差异。

点击提交，准备的字段是 {"day":"2026-10-23"}，没有附加零点、Z或时区偏移。它表达“这一天”，尚未表达“这一天在某个地区的哪个时刻”。如果接口需要后者，应让接口明确要求相应信息。

日期输入的显示，不是提交格式

浏览器可能用当地格式画出日期，用户看见的顺序和分隔符可以不同。读取value得到规范值，不能再从控件截图或本地化显示文字猜提交字符串。

程序也没有读取valueAsDate作为业务字段。它是Date对象，仍然要面对日期与时间点的映射语义；拿到一个对象并不比拿到字符串更“标准”。若业务只需要年月日，保留这份日历字段通常更容易避免无意义转换。

后端也应使用日历日期类型或等价约定，而不是先存成UTC时间再要求每个客户端记得按特殊时区还原。历史接口已经如此存储时，需要先核对现有语义和兼容，不能一边改前端一边让旧客户端继续使用另一套规则。

范围约束验证日期，不验证业务资格

页面只允许2026年，并设为必填。用脚本把value设成2027-01-01，值仍可能存在，但rangeOverflow为true；把无效日期文本赋给date控件，规范化结果可能为空，必填约束随后失败。值存在与值合法不是一回事。

原生提交会进行交互约束验证，因此无效时不会进入示例的submit处理器。检查按钮使用普通button，是为了仍能观察约束状态。若用脚本绕过原生提交流程，不能假定浏览器已经替请求完成验证。

服务器必须重复执行格式、合法日期和业务范围检查。可以选到某天，不代表那天仍有库存或属于允许账期。用户也可以直接构造请求，控件只是交互入口，不能作为后台接受数据的依据。

真正需要时间点时，补的是合同而非一个 Z

“10月23日09:00在某城市开会”还需要当地时间与时区规则。直接在日期字符串后拼T09:00:00Z，会把UTC当成当地时间；加上电脑当前偏移，也未必等于会议所在地或目标日期适用的偏移。

跨夏令时地区还可能存在某个本地时刻不存在，或出现两次的情况。预约系统需要决定怎样拒绝或选择，而不是在前端创建Date后把浏览器的默认结果当成产品规则。日期字段与时间点字段分开建模，才能让这些问题有明确入口。

相反，业务日期不应随观看者旅行改变。用户换到另一个时区查看生日或账单所属日，通常仍应看见原来的年月日。若显示组件必须接收Date，应该先评估组件合同，避免为了迁就组件而改变存储数据含义。

日期字符串也不适合通过毫秒加减推导下一天。对时间点加固定二十四小时，表达的是一段持续时间；对某地区日历日期加一天，还要遵守当地日历与时区规则。业务只有日期时，最好由明确的日期运算层处理，再用规范字段传输，避免在无关环节引入系统本地时区。

同一日期字段的范围还应与后台错误提示保持一致。前端允许全年，后台只接受当前账期时，应解释业务原因，而不是显示“日期格式错误”。格式、日历合法性、控件范围和业务资格是不同拒绝层，混成一个错误会让用户不断重选一个本来合法的日期。

浏览器自动化能够验证规范value和约束标志，却不能替代所有平台的原生日期选择器体验检查。移动端键盘、选日界面与辅助技术呈现可能不同；本文没有声称这些界面都已验收，而是把可重复的日期合同固定下来。

可以用本页留下三个回归样本：默认日期在两时区对应不同本地日、范围外日期被拒绝、合法日期提交时仍保持原字符串。它们验证的是语义没有中途变形，而不只是输入框能选到日期。