ora-01882是客户端时区解析失败，非数据库故障；根本原因是.net运行时或oracle instant client启动时无法匹配服务端时区名（如asia/shanghai），需同步tz环境变量、/etc/localtime软链、timezlrg.dat文件及驱动版本，四者缺一不可。
ORA-01882: timezone region not found 是客户端解析失败，不是数据库故障
这个错误本质是.NET运行时（或底层Oracle Instant Client）在启动时，找不到与Oracle服务端匹配的时区区域名（如 Asia/Shanghai），而非数据库本身异常。Linux容器里尤其高频——默认 TZ 为空或设为 CST，而Oracle驱动只认标准IANA时区名，不认缩写或Windows风格名称（如 China Standard Time）。
Docker容器内必须显式设置TZ并同步/etc/localtime
仅靠 ENV TZ=Asia/Shanghai 不够，.NET应用（尤其是使用 Oracle.ManagedDataAccess.Core）会读取系统时区文件，而Docker基础镜像常缺失软链或内容不一致。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 在
Dockerfile中添加两行（顺序不能颠倒）：ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
- 不要用
apt-get install tzdata后再设时区——Alpine等精简镜像无tzdata包，且dpkg-reconfigure在容器中不可交互 - 验证是否生效：容器启动后执行
date和readlink /etc/localtime，输出应指向/usr/share/zoneinfo/Asia/Shanghai
.NET应用需禁用JVM式时区覆盖逻辑
Oracle.ManagedDataAccess.Core 不响应 -Duser.timezone 这类JVM参数，但会受环境变量和Instant Client行为影响。若你混用了Oracle官方客户端（Oracle.DataAccess）或启用了 OCI 模式，还需检查：
- 确保未在
appsettings.json或连接字符串中传入serverTimezone——这是MySQL参数，Oracle驱动直接忽略 - 若用的是
Oracle.ManagedDataAccess（非Core版），确认oracle.jdbc.timezoneAsRegion=true无效；该参数仅对JDBC驱动起作用 - 避免在代码里调用
TimeZoneInfo.Local后硬编码转换——它依赖OS时区配置，容器里易错
时区文件版本不匹配会导致“明明设对了还报错”
Oracle服务端升级（如19c→23c）后，timezlrg.dat 文件会更新，新增时区或修正历史规则。若Linux服务器或容器内 $ORACLE_HOME/oracore/zoneinfo/timezlrg.dat 版本旧于服务端，即使 TZ=Asia/Shanghai 正确，驱动仍可能因查不到对应条目而 fallback 失败。
- 查服务端时区版本：
SELECT version FROM v$timezone_file; - 查客户端文件时间戳：
stat $ORACLE_HOME/oracore/zoneinfo/timezlrg.dat - 不一致时，从服务端拷贝同名文件覆盖客户端（注意权限保持为
oracle:oinstall） - 没有
$ORACLE_HOME？说明用的是Oracle.ManagedDataAccess.Core——它自带轻量时区数据，但版本必须与服务端兼容；此时应升级NuGet包到匹配版本（如服务端23c，用Oracle.ManagedDataAccess.Core 4.231.1.0）
TZ 环境变量、系统软链、Instant Client内置数据、服务端 v$timezone_file 四者必须严格对齐。少一个环节，ORA-01882 就会复现。
