input type="time" 提交纯时间字符串（如"14:30"），无日期及时区，后端需手动补零、校验格式并明确语义；拼接日期时须用"T"分隔并padStart补零，避免非法ISO格式。
input type="time" 提交的是纯时间字符串，不带日期、不带时区；后端直接拼接或解析时极易出错，必须手动补零、校验格式、明确语义。
提交内容就是 "HH:mm" 或 "HH:mm:ss" 字符串
浏览器对 input type="time" 的 value 值强制标准化：用户选“下午 2:30”，value 是 "14:30"；输“9:5”会被自动修正为 "09:05"；秒字段未启用时不会出现 ":ss" 部分。
- 表单用
POST提交时，该字段的键值对就是name=HH:mm（例如meeting_time=14:30） - 不要依赖
valueAsNumber或valueAsDate——前者返回毫秒数但基准日是 1970-01-01，后者构造出的 Date 对象日期部分恒为Thu Jan 01 1970，毫无业务意义 - 若需秒级精度，必须显式设置
step="1"，否则默认只到分钟（step="60"）
和 date 拼接成 ISO 时间前必须补零、加 T 分隔符
常见错误是把 date.value（如 "2026-09-30"）和 time.value（如 "9:30"）直接拼成 "2026-09-309:30"，这既不是合法 ISO 格式，也无法被 new Date() 正确解析。
- 正确拼法：
date.value + "T" + time.value.padStart(5, "0")（padStart确保"9:30"→"09:30"） - 如果 time 支持秒且用户输入了秒，
time.value可能是"09:30:05"，此时无需额外 pad，但需统一判断长度 - 更稳妥的做法是用
time.value.split(":").map(x => x.padStart(2,"0")).join(":")处理所有情况
datetime-local 能避免拼接，但值不含时区标识
input type="datetime-local" 的 value 是类似 "2026-09-30T14:30" 的字符串，看起来省事，但它**没有 Z 或 +08:00**，JS 解析时会按本地时区解释——在东京用户看到的 “14:30” 和在纽约用户看到的 “14:30”，实际对应 UTC 时间差 13 小时。
立即学习“前端免费学习笔记（深入）”；
- 若业务要求统一按 UTC 存储，必须在 JS 中手动转：用
new Date(input.value)得到本地时间对象，再调.toISOString().slice(0,16)截取前 16 位（如"2026-09-30T06:30"），才能得到等效 UTC 时间字符串 - 后端收到
datetime-local值时，不能直接喂给数据库的TIMESTAMP WITH TIME ZONE类型——它会被当成本地时间处理，导致存储偏差 - 移动端兼容性仍较差（尤其 iOS Safari 旧版本），建议用
Modernizr.inputtypes["datetime-local"]检测并降级为 date+time 组合
后端接收时别用 new Date("14:30") 直接解析
Node.js、Python、PHP 等语言中，用原生日期解析函数处理纯时间字符串，结果不可控：有的默认补 1970-01-01，有的报错，有的按服务器时区补午夜。
- Node.js 推荐用
dayjs(timeString, "HH:mm")或moment(timeString, "HH:mm")显式指定格式 - Python Flask 中，用
datetime.strptime(request.form["time"], "%H:%M")，而不是datetime.fromisoformat() - PHP 应用
DateTime::createFromFormat("H:i", $_POST["time"])，而非new DateTime($_POST["time"]) - 关键原则：纯时间字符串必须配合明确的日期上下文才有意义，单独解析无业务价值
真正麻烦的从来不是怎么让用户选时间，而是你是否清楚这个字符串在每个环节代表什么——前端显示、序列化、传输、后端解析、存储、查询、展示，每一步都可能悄悄改变它的含义。
