必须在Oracle.ManagedDataAccess连接字符串中添加timezoneAsRegion=true，否则ALTER SESSION SET TIME_ZONE='Asia/Shanghai'无效，会导致TIMESTAMP WITH LOCAL TIME ZONE字段读写偏差、ORA-01882错误及夏令时丢失。
Oracle.ManagedDataAccess 连接字符串必须加 timezoneAsRegion=true
不加这个参数，ALTER SESSION SET TIME_ZONE = 'Asia/Shanghai' 基本无效——驱动初始化时就按缩写查 V$TIMEZONE_NAMES，查不到就退化成 +08:00，丢掉夏令时规则和历史修正。即使你连上后立刻执行该语句，后续取 TIMESTAMP WITH LOCAL TIME ZONE 字段时仍可能 fallback 到 JVM 默认时区（如 GMT）。
实操建议：
- 连接字符串中明确添加：
Connection Properties=timezoneAsRegion=true;useFetchSizeWithLongColumn=true - 别用
timeZone或timezone这类模糊键名，Oracle 驱动只认timezoneAsRegion - 验证是否生效：连上后执行
SELECT SESSIONTIMEZONE FROM DUAL，结果必须是Asia/Shanghai，不是+08:00
.NET 运行时默认时区要与 Oracle 服务端对齐
驱动依赖运行时的默认时区做底层解析。Docker 容器里跑 .NET 应用，默认是 UTC；Windows 上可能是 China Standard Time；Linux 上则依赖 TZ 环境变量。三者不一致，timezoneAsRegion=true 就会失效。
实操建议：
- Linux/Docker：启动容器时加
-e TZ=Asia/Shanghai，或在入口脚本中export TZ=Asia/Shanghai - Windows：确保系统时区设为“中国标准时间”，或代码中显式设置
TimeZoneInfo.Local不被覆盖 - 避免靠
DateTime.Now推断——它返回的是Local，但Local的含义取决于运行环境，不可控
TIMESTAMP WITH LOCAL TIME ZONE 字段读写必须配合会话时区
TIMESTAMP WITH LOCAL TIME ZONE 类型在 Oracle 内部存的是 UTC，但 SELECT 时自动转成当前会话时区显示。如果 .NET 驱动没正确同步会话时区，读出来的值可能错偏 8 小时，甚至抛 ORA-01882: timezone region not found。
常见错误现象：
- 数据库里存的是
2026-07-21 15:00:00（上海时间），.NET 读出来变成2026-07-21 07:00:00 - 执行
SELECT SESSIONTIMEZONE FROM DUAL显示+08:00，但驱动内部仍用GMT解析 - 客户端
timezlrg.dat版本比服务端旧（比如服务端是 23c，客户端是 19c），Asia/Shanghai被识别为废弃别名
解决路径：
- 确认 Oracle 服务端版本，下载对应
timezlrg.dat替换到 .NET 应用所在机器的$ORACLE_HOME/oracore/zoneinfo/目录下（若未部署完整 Oracle Client，需手动补全） - 不要在应用层对
TSLTZ字段做ToString()后再解析——它已是本地时区值，再转容易二次偏移
绕过驱动限制：用 TO_CHAR + TZ_OFFSET 在 SQL 层做时区转换
当无法控制连接参数或客户端环境（如嵌入 Infor LN ERP 的定制模块），可放弃依赖会话时区，改用 Oracle 函数在 SQL 层动态计算偏移。
示例（用户时区传入为 '-05:00'）：
SELECT TO_CHAR(A.T$CNFT AT TIME ZONE 'UTC' AT TIME ZONE '-05:00', 'YYYY-MM-DD HH24:MI:SS') AS ConfirmedTime FROM MYTABLE A
或者更轻量的偏移计算（仅适用于无夏令时场景）：
SELECT TO_CHAR(A.T$CNFT + NUMTODSINTERVAL(SUBSTR('-05:00', 1, 3), 'HOUR'), 'YYYY-MM-DD HH24:MI:SS') AS ConfirmedTime
FROM MYTABLE A
注意点：
-
AT TIME ZONE要求 Oracle 9i+，且目标时区名必须存在于V$TIMEZONE_NAMES；传缩写（如CST）风险高 - 用
TZ_OFFSET计算偏移量虽灵活，但不处理夏令时切换，仅适合固定偏移需求 - 这类写法把时区逻辑推给数据库，应用层变简单，但性能受制于 Oracle 的时区函数开销，高频查询慎用
