应存用户选择的IANA时区名（如"Asia/Shanghai"）为独立字段，后端用其将本地时间转UTC存入timestamptz；前端展示时用toLocaleString配合该时区还原。
用户选的时区怎么存进数据库
浏览器里 Intl.DateTimeFormat().resolvedOptions().timeZone 能拿到用户本地时区名（比如 "Asia/Shanghai"），但别直接塞进后端字段。多数数据库不认这个字符串，也不该存它。
更稳妥的做法是：表单提交时，把用户选择的时区名（或通过 select 下拉传来的值）作为独立字段传给后端，比如 timezone 字段，值为 "Europe/Berlin"；后端收到后，用它解析用户提交的时间字符串（如 "2024-06-15T14:30"），转成 UTC 时间再存入数据库的 datetime 或 timestamptz 字段。
- 前端不要自己用
new Date().getTimezoneOffset()算偏移量——夏令时会让这个值变，且无法反推时区名 - 下拉选项建议用 IANA 时区名（
"America/New_York"），不是缩写（"EST"）或固定偏移（"UTC+5"），后者无法处理夏令时切换 - 如果后端用 PostgreSQL，字段类型优先选
timestamptz，它会自动按传入时区转 UTC 存储
HTML 下拉菜单怎么列出合理时区选项
别手写几十个时区选项，也别只列“北京时间”“纽约时间”这种模糊叫法。用户需要可识别、可持久化、能被服务端正确解析的值。
推荐用 JS 动态生成，基于 Intl.supportedValuesOf('timeZone')（现代浏览器支持），过滤掉泛用性差的（如 "Etc/GMT+0"），再按地理区域分组排序。常见错误是把 "UTC" 和 "GMT" 当作不同选项——它们在语义和计算上等价，留一个就行。
立即学习“前端免费学习笔记（深入）”；
- 避免包含
"SystemV/"或"Factory"这类已废弃的时区名 - 中文界面里，显示名可用本地化描述（如
"北京时间（中国标准时间）"），但value必须是标准 IANA 名"Asia/Shanghai" - 移动端要注意：iOS Safari 对
Intl.supportedValuesOf支持较晚（iOS 16.4+），降级方案是预置一份精简列表（约 80 个常用时区）
用户提交时间后，页面回显为什么总是错位
典型现象：用户在东京选了 "2024-06-15 10:00"，提交成功，页面再渲染这个时间却显示成 "2024-06-14 21:00"。根本原因是前后端对“这个时间属于哪个时区”没对齐。
后端返回的时间字段如果是纯字符串（如 "2024-06-15T01:00:00Z"），前端用 new Date() 解析默认按本地时区解释；如果后端返回的是带时区信息的 ISO 字符串（如 "2024-06-15T10:00:00+09:00"），那没问题；但如果返回的是无时区的 "2024-06-15 10:00:00"，前端就只能靠额外字段（如 timezone: "Asia/Tokyo"）来还原。
- 后端 API 应统一返回带时区的 ISO 8601 字符串（
"2024-06-15T10:00:00+09:00"），而不是“本地格式” - 前端展示时，用
toLocaleString配合用户偏好时区（而非浏览器默认）：date.toLocaleString('zh-CN', { timeZone: userTimezone }) - 别依赖
Date.prototype.toString()或toUTCString()做展示——它们输出格式不可控，且隐含时区假设
Node.js / Python 后端解析时区输入容易漏什么
收到前端传来的 timezone="Asia/Kolkata" 和 datetime="2024-06-15T12:00"，直接拼成字符串再 parse，大概率出错。Node.js 的 dayjs 或 date-fns-tz、Python 的 pytz 或 zoneinfo 都要求明确区分“时间字符串本身有没有时区信息”。
例如：Python 中 datetime.fromisoformat("2024-06-15T12:00") 返回的是 naive datetime（无时区），必须显式绑定：zoned = local_dt.replace(tzinfo=ZoneInfo(timezone))，再转 UTC；Node.js 用 date-fns-tz 则要走 zonedTimeToUtc(datetimeStr, timezone)，不能用 parseISO 后再 setZone。
- Node.js 若用
moment-timezone，注意moment.tz(str, zone)要求str是本地时间字符串（不含时区），否则行为异常 - Python 3.9+ 推荐用
zoneinfo.ZoneInfo，别用已弃用的pytz.timezone直接构造 naive datetime - 所有解析操作前，先校验
timezone是否在Intl.supportedValuesOf('timeZone')或后端白名单内，防止注入非法值（如"../../../../etc/passwd"）
