alter session set time_zone在.net/jdbc中基本无效，因驱动初始化即锁定时区策略并覆盖会话设置；必须协同配置连接参数timezoneasregion=true、jvm/运行时默认时区、客户端timezlrg.dat文件与服务端版本一致。
直接设 sessiontimezone 不可靠，jdbc 驱动会忽略它；必须靠连接参数和 jvm 时区协同控制。
为什么 ALTER SESSION SET TIME_ZONE 在 .NET（或 JDBC）里基本没用
Oracle 的 ALTER SESSION SET TIME_ZONE = 'Asia/Shanghai' 确实能改会话时区，但 .NET 的 Oracle.ManagedDataAccess 或 Java 的 JDBC 驱动在建立连接后会立即覆盖这个设置——尤其是当列类型是 TIMESTAMP WITH LOCAL TIME ZONE 时，驱动按自己的逻辑重算时区，不读你刚设的 session 值。
常见现象：执行完 ALTER SESSION 再查 SELECT SESSIONTIMEZONE FROM DUAL 看起来是对的，但取 TSLTZ 字段值时仍变成 +08:00 或 GMT+0，甚至抛 ORA-01882: timezone region not found。
- 根本原因是驱动初始化阶段就锁定了时区解析策略，后续 SQL 不影响底层时区映射
- .NET 的
OracleConnection没有暴露“强制刷新会话时区”的 API，不能像 PL/SQL 那样反复调用 - 即使连上后立刻执行
ALTER SESSION，驱动在 fetch 阶段仍可能 fallback 到 JVM 默认时区（如GMT）
oracle.jdbc.timezoneAsRegion=true 是关键开关
这是 Oracle JDBC 驱动（v12.2+）提供的核心修复项，.NET 的 Oracle.ManagedDataAccess 从 19.15 开始也支持等效行为（通过 Connection Properties 透传）。不设它，驱动会把 Asia/Shanghai 当成缩写去查 V$TIMEZONE_NAMES，查不到就退化为 +08:00，丢失夏令时规则和历史修正能力。
实操建议：
- 连接字符串里加：
Connection Properties=timezoneAsRegion=true;useFetchSizeWithLongColumn=true - 确保 JVM 启动参数设了
-Duser.timezone=Asia/Shanghai（.NET 运行时等效于设置TimeZoneInfo.Local或环境变量TZ=Asia/Shanghai） - 别用
timeZone这种模糊参数名——Oracle 驱动只认timezoneAsRegion和useFetchSizeWithLongColumn - 验证是否生效：连上后执行
SELECT SESSIONTIMEZONE FROM DUAL，结果必须是Asia/Shanghai，不是+08:00
客户端 timezlrg.dat 文件必须和服务端一致
Oracle 驱动依赖本地 $ORACLE_HOME/oracore/zoneinfo/timezlrg.dat 解析时区名。如果服务端是 23c（带新版时区数据），而 .NET 应用跑在 Docker 容器里、只装了 19c 客户端，那么 Asia/Shanghai 可能被识别为废弃别名，直接报 timezone region not found。
排查步骤：
- 进容器或部署机，检查
timezlrg.dat时间戳：ls -l $ORACLE_HOME/oracore/zoneinfo/timezlrg.dat - 和服务端同路径文件比对（注意：不是看版本号，是看 mtime）
- 不一致就从服务端
scp一份过去，chown oracle:oinstall，然后重启应用 - 别指望
utlrp.sql或catuppst.sql更新它——它们不碰时区文件
真正麻烦的点不在代码里，而在部署环境：JVM 时区、驱动参数、客户端时区文件、数据库服务端版本，四者必须对齐；漏一个，TIMESTAMP WITH LOCAL TIME ZONE 就会静默出错，且很难从日志定位。
