先记住这个答案
datetime-local 把日期和时间放在一个输入里，但名字中的 local 指没有时区信息的本地日期时间。它的 value 类似 2026-10-09T14:30，不是带 Z 的 UTC 时间，也不是自动附带当前浏览器时区。若给异地用户预约会议，后端必须额外知道这个本地时间对应哪个时区。
- 值包含日期、
T与本地时间 - 值本身没有时区偏移
- 可用
min、max限制范围 - 跨地区预约需另存时区
一个值包含哪些字符
日期和时间之间用大写 T 分隔，常见到分钟精度；根据 step 还可能出现秒等更细的部分。表单提交时浏览器对字段值进行编码，但不会凭空加上 UTC 偏移。和分别使用 date、time 两个字段相比，它方便用户一次选择完整的本地日期时间，语义仍由业务决定。
<label for="meeting">会议时间</label>
<input id="meeting" name="meeting" type="datetime-local"
min="2026-10-01T09:00" max="2026-10-31T18:00">
<!-- value 示例：2026-10-09T14:30 -->min 和 max 也使用同类本地日期时间格式。若会议固定在某个城市，界面还应说明时区，例如“上海时间”，并把时区作为单独业务字段或服务器上下文保存。
什么时候要做时区转换
旅行、远程会议和跨地区服务都需要唯一时间点。2026-10-09T14:30 在上海和纽约并非同一时刻；服务器若直接按自己的本地时区解析，会给用户安排错误时间。收到值后，应结合明确的时区标识解析，再存统一时间点。
夏令时切换地区还会出现不存在或重复的本地时间。遇到这类预约，后端需要制定校验和消歧规则，而不能认为一个 datetime-local 字符串天然唯一。生日这类纯日期不应为此强行转换成时间戳。
例如用户在上海输入 2026-10-09T09:00，在洛杉矶输入同样的值，控件提交的字符串完全一样，代表的真实时刻却不同。若系统要安排跨地区会议，只存这个字符串会丢失关键信息；应同时收集或由业务明确约定 IANA 时区，如 Asia/Shanghai，再在服务端换算成统一时刻。夏令时切换当天还有“本地时间不存在或出现两次”的情况，不能简单地给字符串拼上 Z 了事。
容易答错的地方
- 认为 local 等于用户浏览器时区已提交
- 控件值没有提交时区。浏览器所在地区也不一定是预约所属地区。
- 直接在末尾补
Z Z表示 UTC；给本地时间硬补Z会改变原本代表的时刻。
面试官还会怎么问？
datetime-local 和 date 的核心区别？
前者带本地时间，后者只有日历日期；两者的值都不含时区。
能直接用它安排全球会议吗？
还需明确时区，并处理夏令时可能造成的不存在或重复本地时间。
为什么名称里没有旧式 datetime？
当前控件设计强调本地日期时间字符串，不自动提供时区信息。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。