Oracle 19中FROM_TZ转换2020年后Europe/Paris时区时间返回异常

这个问题和NLS参数配置无关，本质是Oracle 19c自带的32版DST时区文件（timezlrg_32.dat）存在规则错误：

• 32版时区文件发布时，误将欧盟当时尚未落地的“2021年起永久取消夏令时”草案作为正式规则写入，给'Europe/Paris'时区配置了2021年之后固定使用UTC+1偏移的错误规则。
• 实际上法国最终并未执行取消夏令时的政策，2021年及之后仍然保持原有夏令时（每年3-10月UTC+2）、冬令时（10月-次年3月UTC+1）的切换逻辑。
• 这就直接导致：2020年的时区转换因为在错误规则生效节点前，结果完全正常；2021年6月属于夏令时时段，本该按UTC+2计算，却被错误按UTC+1偏移处理，最终出现输入10:00、返回09:00的偏差。

你贴出的NLS会话参数均为法国本地化环境的正常配置，不会触发这个时间偏差问题。

按优先级从高到低可选以下方案：

• 推荐永久修复：给数据库打DST时区升级补丁，将时区文件升级到35及以上版本。35及之后的版本已经修正了欧盟夏令时规则的误判，同步了欧洲各国2021年之后的实际夏令时执行政策，补丁打完后不需要修改任何业务SQL，重新执行原查询就能得到正确结果。操作前记得做好全库备份，严格按照补丁配套的操作指引执行，升级完成后可以通过SELECT * FROM V$TIMEZONE_FILE;确认版本号，再跑测试SQL验证结果。
• 临时规避方案：如果短时间内无法安排补丁升级，可以暂时不使用'Europe/Paris'时区名称，直接根据时段指定固定时区偏移（夏令时用'+02:00'，冬令时用'+01:00'）。这个方案需要业务代码自行判断夏令时切换节点，维护成本很高，只适合应急使用。
• 注意：不要尝试通过修改NLS参数、调整数据库默认时区的方式解决问题，这类操作无法修正时区文件内置的规则错误，反而可能引入新的时间计算问题。

内容的提问来源于stack exchange，提问作者ulk200