datetime-local 的 value 默认为本地时区时间，隐含偏移但不显示；必须用 new date(input.value) 解析为 date 对象，再通过 toisostring() 转 utc 字符串（如 "2024-06-15t06:30:00.000z"）传给后端，不可直接发送 input.value。
datetime-local 的值默认就是本地时区时间，不需要额外转换
你用 <input type="datetime-local"> 选的时间，浏览器提交或读取 value 时，得到的是 ISO 8601 格式字符串（如 "2024-06-15T14:30"），但它**隐含本地时区偏移**，只是不显示在字符串里。这个值在 JS 中调用 new Date(input.value) 会自动按用户本地时区解析，不是 UTC。
直接读 value 会丢失时区信息，必须用 Date 构造函数还原
input.value 返回的字符串没有时区标识（Z 或 ±hh:mm），所以不能直接当 UTC 时间用，也不能跨时区可靠比较。常见错误是直接传给后端或存数据库，结果在不同时区设备上含义不一致。
- ✅ 正确做法：用
new Date(input.value)转成 Date 对象，它内部已按本地时区计算出毫秒时间戳 - ❌ 错误做法：直接发送
input.value字符串到后端，后端按 UTC 解析（比如 Python 的datetime.fromisoformat()会报错或误判） - ⚠️ 注意：
new Date("2024-06-15T14:30")在上海和纽约都会生成各自本地时间对应的 Date 实例，不是统一时刻
想传标准 UTC 时间给后端？得手动转
如果后端需要 UTC 时间（比如存入 PostgreSQL 的 TIMESTAMP WITH TIME ZONE），必须显式转换：
const input = document.querySelector('input[type="datetime-local"]');
const localDate = new Date(input.value);
const utcString = localDate.toISOString(); // 如 "2024-06-15T06:30:00.000Z"
关键点：
-
toISOString()总返回 UTC，且带Z后缀，语义明确 - 不要用
toUTCString()或拼接字符串，格式不标准、易出错 - 如果后端要的是“带本地偏移的 ISO 字符串”（如
"2024-06-15T14:30:00+08:00"），用localDate.toLocaleString("sv-SE", { timeZoneName: "short" })配合正则提取，但不如直接传 UTC 简单可靠
兼容性差，移动端行为不一致
datetime-local 在 iOS Safari 和部分旧 Android 浏览器里不支持，或者弹出的是纯时间选择器（无日期）。即使支持，iOS 上选的时间可能被强制转成 UTC 再塞进 value（bug 级别），导致 new Date(input.value) 解析错误。
- 检测是否可用：
const support = typeof document.createElement('input').type === 'string' && 'datetime-local' in document.createElement('input').type - 生产环境建议 fallback 到两个独立
date+time输入框，或用第三方库（如 flatpickr）统一处理 - 真要用，务必在真实 iOS 设备上测试，不能只信桌面 Chrome 模拟
input.value 是“带时区的”，结果直接发给后端，一到欧洲用户那儿时间就错 6 小时。本质不是 API 问题，而是对这个控件返回值的时区语义没吃透。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
