Open
Description
Fetching timestamp with time zone raises error ORA-01805: possible error in date/time operation
instead of returning datetime with time zone information.
-
What versions are you using?
- database version: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
- platform.python_version: 3.9.9
- oracledb.__version__: 1.0.1
-
Is it an error or a hang or a crash? Error
-
What error(s) or behavior you are seeing?
Error oracledb.exceptions.DatabaseError: ORA-01805: possible error in date/time operation
is raised when trying to use at time zone
in SQL . Below is a sample code to reproduce the problem.
-
Does your application call init_oracle_client()? Yes, uses Thick mode.
-
Include a runnable Python script that shows the problem.
import oracledb
from oracledb.thick_impl import init_oracle_client
def f(sql):
with oracledb.connect(user='hr', password='password', dsn='127.0.0.1:1511/xe') as connection:
with connection.cursor() as cursor:
query = cursor.execute(sql)
row = query.fetchone()
print(row[0].time())
init_oracle_client()
# this works because returns datetime without time zone
f("select systimestamp from dual")
# this raises error ORA-01805
f("select systimestamp at time zone 'America/Montreal' as d from dual")
# this is manual walkaround but datetime is still missing time zone information
f("select cast(systimestamp at time zone 'America/Montreal' as timestamp) as d from dual")
The above is an example using systimestamp but similar error can be achieved by crating table with column type timestamp with time zone
create table tz_table
(
tz_timestamp TIMESTAMP(6) WITH TIME ZONE not null
);
insert into tz_table values ( TIMESTAMP '2022-06-16 08:00:00 US/Central');
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
cjbj commentedon Jun 19, 2022
This is an Oracle Client library issue. We saw the same problem once in the past for cx_Oracle with an application using timezone v35 files. There was no problem when that application used v36 files. We logged it as Oracle bug 33576821, which is still open - since there was a simple solution.
If you can share any other details such as machine timezone settings and environment variables I can add it to the bug to help identify what triggers it.
Some thoughts:
mdobrzanski commentedon Jul 4, 2022
I've done some more testing and found that the timestamp with time zone works correctly when ORA_TZFILE is the same on server and client. I had similar problems with cx_Oracle and posted there a question oracle/python-cx_Oracle#631
I couldn't find v36 files. Older versions I found in official docker images. @cjbj could you point me where I could the v36 from? Maybe v36 in client would work correctly with older server time zone versions.
Interesting is that with client 21 I was able to connect to server 11 although the official OCI download page says different
Below OCI 21.6
anthony-tuininga commentedon Jul 8, 2022
What I have discovered is that everything works as expected with numeric timezone data (-05:00 instead of US/Central, for example). The thin driver doesn't handle named time zones properly either -- so that needs to be addressed (either raising an error like the thick driver or something better than that if possible!). The problem with using named time zones is that everyone has to agree on what they mean. I'll ask internally if there is a way to mitigate this.
cjbj commentedon Jul 11, 2022
The v36 files were probably from an internal build.
Regarding 21->11 connectivity, there's sometimes a difference between what's technically possibly vs what is 'supported' in the tested & "you can call us if there is a problem" way.
agilevic commentedon Mar 17, 2023
@anthony-tuininga @cjbj are we in agreement that currently the only viable work-around is to use numerical hour offset?
Also, can you share where can we track progress of the issue reported with Oracle client library (33576821)?
cjbj commentedon Mar 20, 2023
@agilevic Any decision on named timezones is still pending. And so is that bug - sorry.
anthony-tuininga commentedon Mar 20, 2023
@agilevic, the current viable workaround for the issue is to use numerical time zone offsets when using thin mode. I will probably add an exception for version 1.2.3 and will then discuss further what to do for version 1.3 -- watch this space!
agilevic commentedon Mar 20, 2023
Thank you, both. For what it's worth our workaround has been to cast TIMESTAMP WITH TIMEZONE, which might be required in query logic (join) to regular TIMESTAMP in the SELECT clause for the output. In many cases this is sufficient in the client application, but of course only covers some use cases and can slow down query performance.
khooz commentedon Jul 5, 2023
Having the same issue using thick mode.
I don't know why named zones don't work even using the latest instant client dll in thick mode using (almost) latest tzdata file and the large timezone file. Doesn't the module use all the instant client features? The same instant client works for PHP OCI and SQLDeveloper. I'd be happy to provide any necessary information to help resolve this faster.
the code
damilareisaac commentedon Feb 14, 2024
I ran into this issue. Upgrade from oracle_cx. It is not possible to update the oracle database as it is serving a legacy application.
Now getting the exception message: _named time zones are not supported in thin mode
Any solution on how to fix this?
anthony-tuininga commentedon Feb 15, 2024
You can use thick mode to fetch timestamp with timezone using named time zones or you can use numeric offsets. The support for named time zones in thin mode is on a long list of enhancement requests!
[-]timestamp with time zone[/-][+]Add support for named time zones in thin mode[/+]anthony-tuininga commentedon Feb 15, 2024
I've changed this to an enhancement request so it can be tracked.
damilareisaac commentedon Feb 22, 2024
Not working in thick mode either. got the error:
sqlalchemy.exc.DatabaseError: (oracledb.exceptions.DatabaseError) ORA-01805: possible error in date/time operation
I am not sure what you mean by numeric offset. if you can please give an example. I tried changing timestamp to Numeric in the ORM schema, got the error:
FAILED tests/integration/test_api/test_ppts.py::test_get_all_ppts - sqlalchemy.exc.DatabaseError: (oracledb.exceptions.DatabaseError) ORA-00932: inconsistent datatypes: expected NUMBER got TIMESTA...
damilareisaac commentedon Feb 22, 2024
Full traceback
Using oracledb 2.0.1
anthony-tuininga commentedon Feb 25, 2024
The error
ORA-01805: possible error in date/time operation
generally implies that you have a different client version than the database version. If you make them match the issue should go away. As noted you can also avoid using named time zones (as inalter session set time_zone = 'America/Edmonton'
) and instead use numeric time zone offsets (as inalter session set time_zone = '-06:00'
).nmoreaud commentedon Jun 25, 2024
As a workaround, what can I use to transform a timestamp to UTC?
Are these query equivalent?
anthony-tuininga commentedon Jun 25, 2024
They should indeed be equivalent.
ggasnier72 commentedon Jun 28, 2024
We are using current_timestamp to update timestamp with time zone column.
The trigger is defined on the table A where the timestamp with time zone column is available.
With updates on some fields, the trigger is called and the column is updated with current_timestamp.
The driver gets the value back with this format: 'DD-MM-YY HH24:MI:SSXFF TZH:TZM'
Trigger's code:
Triggers are also defined on other tables. Updates on some fields update the column of the table A.
Trigger's code:
Without the explicit conversion, the value in the column is not correct. Its format is 'DD-MM-YY HH24:MI:SSXFF TZR'.
And the driver can't get the value back because of the exception: DPY-3022: named time zones are not supported in thin mode
It seems that in the second trigger, if we use curTime := current_timestamp, the database NLS_TIMESTAMP_TZ_FORMAT parameter is used.
Do you think there are other alternatives to get the correct format ?
Do you have a roadmap that includes timezone support ?
nmoreaud commentedon Jun 28, 2024
@ggasnier72 presents a use case we are working on.
We want to store a "last modified date" (UTC) information on a root object (ex "order").
Each update on a sub-object (ex order_product, delivery, parcel, address) must also update the root object "last modified date", via a trigger.
We have implemented it successfully for multiple database providers, but we have difficulties with Oracle because of the driver has date support limitations:
We are looking for a solution which will not regress with a future update of OracleDB driver.
Maybe a discussion would be more appropriate.
A629142 commentedon Nov 7, 2024
+1
DinnieJ commentedon Dec 11, 2024
Is there any update on this ?
cjbj commentedon Dec 11, 2024
@DinnieJ no update. My general recommendation is the same: use UTC in the DB and mid-tier (e.g. if you are using Python in a service), and do conversions in the presentation layer (e.g. browser layer)