to_char 根据调用过程的位置产生不同的输出
我们正在使用远程系统提供的存储过程。出于测试目的，我从我的开发机器上调用此过程。现在的问题是，如果我从 Toad 调用该过程，一切都会正常。但是当我使用 SQL Developer 调用它时，会发生错误。
我调试了又调试，发现了这一点：在该过程中，生成了一个到期日期并将其传递给网络服务（不要问我为什么）。
以下是负责生成日期的行：
vt_User.EXPDATE := TO_DATE('01.01.2025', 'dd.mm.yyyy');
vs_Value := to_char(vt_User.EXPDATE, 'YYYY-MM-DD"T"HH24:MI:SSTZR');
vs_Value，当从 Toad 调用时，生成如下：
2025-01-01T00:00:00+02:00
但如果我从 SQL Developer 调用，则类似于：
2025-01-01T00:00:00EUROPE/ATHENS
除了这些行之外的所有内容都是完全一样。我尝试了许多不同的方法，尝试设置 NLS_LANG、更改会话等，但没有结果。
我需要解决这个问题，因为当我从 Java 代码调用该过程时也会发生同样的事情，这就是主要问题。
我使用 Toad 和 SQL Developer 的 TNS、Java 代码的瘦驱动程序 连接到远程数据库。
We're using a stored procedure provided by a remote system. For testing purposes, I call this procedure from my development machine. Now the problem is if I call the procedure from Toad, everything is OK. But when I call it using SQL Developer an error happens.
I debugged and debugged and found out this: In the procedure, an expire date is generated and passed to a web service (don't ask me why).
Here are the lines responsible for generating the date:
vt_User.EXPDATE := TO_DATE('01.01.2025', 'dd.mm.yyyy');
vs_Value := to_char(vt_User.EXPDATE, 'YYYY-MM-DD"T"HH24:MI:SSTZR');
vs_Value, when called from Toad is generated like:
2025-01-01T00:00:00+02:00
But if I call from SQL Developer, it's like:
2025-01-01T00:00:00EUROPE/ATHENS
Everything except these lines are exactly the same. I tried many different approach, trying to set NLS_LANG, altering the session etc but to no result.
I need to solve this because the same thing happens when I call the procedure from Java code also and that's the main issue.
I connect to the remote database using TNS for Toad and SQL Developer, thin driver for the Java code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 Oracle DB 中，您基本上有一个数据库的 TIME_ZONE 定义，但您可以为会话更改它。
在这种情况下，DB time_zone 设置为与 UTC 格式的绝对偏移量，这正是您想要的。
SQL Developer 可能以时区区域名称格式打开会话，如下所示：
因此，将会话更改为 dbtimezone 可能会有所帮助。
In Oracle DB you basically have a TIME_ZONE definition for the DB, but you can change it for a session.
In this case the DB time_zone is set in the Absolute offset from UTC format which is what you want.
Probably the SQL Developer opened the session in Time zone region name format, as could be seen with:
So, altering the session to be as dbtimezone may help.
使用 tzh 和 tzm 有另一个解决方案：
have another solution using tzh and tzm: