数据库视图不自动处理时区，需依赖函数实现；mysql的convert_tz()因time_zone_name表为空常返null；postgresql的at time zone语义易误解；sql server对datetime需先用todatetimeoffset显式标注偏移；所有方案均不支持视图内动态时区切换。
视图本身不能“自动”处理时区逻辑，它只是封装查询；真正起作用的是你写在 SELECT 里的转换函数——而这些函数是否可靠、是否可移植、是否踩坑，全看你怎么用。
MySQL 视图里用 CONVERT_TZ() 为什么总返回 NULL？
不是语法错，是环境没准备好。该函数依赖 mysql.time_zone_name 表，如果为空，任何调用都返回 NULL。
- 先检查：
SELECT COUNT(*) FROM mysql.time_zone_name;—— 结果为 0 就得加载 - 加载命令（Linux）：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql - 时区名必须严格匹配表中
Name字段值，'Asia/Shanghai'可行，'CST'或'UTC+8'不行 -
CONVERT_TZ()第一个参数必须是DATETIME类型，不能是字符串字面量；若字段是VARCHAR，得先用STR_TO_DATE()转
PostgreSQL 视图里用 AT TIME ZONE 的链式陷阱
它不是“把时间从 A 时区转到 B”，而是“把输入值按某时区解释，再转成目标时区的 TIMESTAMPTZ”。语义反直觉，极易翻车。
- 源字段是
TIMESTAMP WITHOUT TIME ZONE（常见）：直接写created_at AT TIME ZONE 'Asia/Shanghai'，PostgreSQL 默认把它当「当前会话时区时间」解释，不是你想的「东八区时间」 - 正确写法（东八区原始时间 → UTC）：
created_at AT TIME ZONE 'Asia/Shanghai' AT TIME ZONE 'UTC' - 时区名必须是 IANA 格式（
Asia/Shanghai），Windows 名（China Standard Time）会报错 - 如果源字段其实是
TIMESTAMPTZ，那第一层AT TIME ZONE是冗余的，直接created_at AT TIME ZONE 'America/New_York'即可
SQL Server 视图里用 AT TIME ZONE 必须绕过 DATETIME
对 DATETIME 或 DATETIME2 直接用 AT TIME ZONE，SQL Server 会静默按服务器本地时区解释输入值，结果完全不可控。
- 错误示范：
order_time AT TIME ZONE 'Eastern Standard Time'（order_time是DATETIME2）→ 实际按服务器所在时区转，非预期 - 正确路径：先用
TODATETIMEOFFSET(order_time, '+08:00')显式打上源偏移，再链式转换：TODATETIMEOFFSET(order_time, '+08:00') AT TIME ZONE 'UTC' AT TIME ZONE 'Eastern Standard Time' - 目标时区名必须是 Windows 时区 ID（查
sys.time_zone_info），Asia/Shanghai会失败 - 别用
GETDATE()或CURRENT_TIMESTAMP做基准——它们返回的是会话时区时间，视图复用时行为不一致
最易被忽略的一点：所有数据库的时区转换函数，在视图定义里都是静态表达式，无法根据用户请求动态切换目标时区。真要支持多时区展示，要么拆成多个视图（如 orders_shanghai、orders_ny），要么把转换逻辑彻底交给应用层——数据库只存 UTC，由代码决定怎么显示。
