Fetching DATE/TIMESTAMP as DF converts to UTC TZ

[mauropagano]

1. What versions are you using?
   3.1.1, db version doesn't seem relevant

2. Is it an error or a hang or a crash?
   Unexpected tz conversion.
   From the source code I think this might be in Arrow space seems to be a decision in the bridge code, but the outcome is very confusing.

3. What error(s) or behavior you are seeing?
   When fetching DATE/TIMESTAMP, the Arrow values are casted transparently to UTC.
   This is inconsistent with regular cursor fetch.

4. Does your application call init_oracle_client()?
   Occurs in both thick and thin mode.
   Also seems to ignore session TIME_ZONE.

5. Include a runnable Python script that shows the problem.

# I'm at America/Los_Angeles that is currently UTC-7
import oracledb
import pyarrow as pa

SQL = "select * from t_ts"
conn = oracledb.connect("...")
cursor = conn.cursor()
try:
    cursor.execute("drop table t_ts")
except Exception:
    pass
cursor.execute(
    "create table t_ts as select sysdate d1, trunc(sysdate) d2, systimestamp t1 from dual"
)

print(cursor.execute(SQL).fetchall())
# clean values as-is
# [
#   (datetime.datetime(2025, 5, 28, 11, 1, 11), 
#    datetime.datetime(2025, 5, 28, 0, 0),   
#    datetime.datetime(2025, 5, 28, 11, 1, 11, 875060)
# )]

odf = conn.fetch_df_all(SQL)
print(pa.Table.from_arrays(odf.column_arrays(), names=odf.column_names()))
# values below are TZ adjusted
# pyarrow.Table
# D1: timestamp[s]
# D2: timestamp[s]
# T1: timestamp[us]
# ----
# D1: [[2025-05-28 18:01:11]]
# D2: [[2025-05-28 07:00:00]]  
# T1: [[2025-05-28 18:01:11.875060]]

[anthony-tuininga]

I have pushed a patch that should correct this issue and have initated a build from which you can download pre-built development wheels once it completes. You can also build from source if you prefer. If you can test your scenario and confirm the patch works as expected, that would be appreciated!

[gleroi]

i have tested on my data: dates that becomed 2025-03-22 23:00:00 are now 2025-03-22 00:00:00 as expected ! thanks for the fix.

[mauropagano]

Looks great, thank you @anthony-tuininga !

Btw tried to extract 1M rows (same table above, just 1M rows) and even with the fix it's still quite faster than a .fetchall()

[cjbj]

Thanks to @suraj-ora-2020 for the base fix for this and also the Windows 1970 issue.