You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using timezone aware datetime bind variables, the value passed to the server has the same date/time components as the bind variable but the time zone is changed to UTC regardless of session time zone.
I'm aware that named time zones are not supported, but that change messes up data. imho proper behaviors could be:
passing UTC offset as TZ info (instead of original named time zone)
pass UTC as TZ info but with date/time components adjusted accordingly
I have tested version 2.3.0 of the driver, both thin and thick modes, with 12.2 and 19.13 databases. Running below script in thin mode with a 19.13 database, produces next output
platform.platform: Linux-6.9.12-200.fc40.x86_64-x86_64-with-glibc2.39
sys.maxsize > 2**32: True
platform.python_version: 3.9.19
oracledb.version: 2.3.0
database version: 19.13.0.0.0
Session time zone: -04:00
Stored old value: 2024-08-04T12:11:13.123-04:00
Parsed old value: 2024-08-04T12:11:13.123
Binding variable: 2024-08-04T13:24:45.272-04:00
Stored new value: 2024-08-04T13:24:45.272+00:00
Parsed new value: 2024-08-04T13:24:45.272
Python script that shows the problem
fromdatetimeimportdatetime, timezonefromosimportenvironfromplatformimportplatform, python_versionfromsysimportmaxsizefromoracledbimport (
DB_TYPE_TIMESTAMP_TZ,
clientversion,
connect,
init_oracle_client,
version,
)
# read connect info and mode from environment variablesthick_mode=environ.get("DB_THICK_MODE", "false").lower() =="true"dsn=environ.get("DB_DSN", "localhost:1521/orcl")
user=environ.get("DB_USER", "scott")
password=environ.get("DB_PASSWORD", "tiger")
# sql statementssession_stmt=r"select sessiontimezone from dual"select_stmt=r"""select to_char(test_ts, 'yyyy-mm-dd"T"hh24:mi:ss.fftzh:tzm'),test_ts from test_tz where test_id = 1"""update_stmt=r"update test_tz set test_ts = :dt where test_id = 1"print("platform.platform:", platform())
print("sys.maxsize > 2**32:", maxsize>2**32)
print("platform.python_version:", python_version())
print("oracledb.version:", version)
ifthick_mode:
init_oracle_client()
print("client version:", ".".join(str(n) forninclientversion()))
withconnect(dsn=dsn, user=user, password=password) asconn:
print("database version:", conn.version)
withconn.cursor() ascursor:
# get session time zonecursor.execute(session_stmt)
print("\nSession time zone:", cursor.fetchone()[0])
# read old valuecursor.execute(select_stmt)
result=cursor.fetchone()
print("\nStored old value:", result[0])
print("Parsed old value:", result[1].isoformat(timespec="milliseconds"))
# update with current date truncated to millisecondsdt=datetime.now(timezone.utc).astimezone()
dt=dt.replace(microsecond=dt.microsecond//1000*1000)
print("\nBinding variable:", dt.isoformat(timespec="milliseconds"))
cursor.prepare(update_stmt)
cursor.setinputsizes(dt=DB_TYPE_TIMESTAMP_TZ)
cursor.execute(None, dt=dt)
# read new valuecursor.execute(select_stmt)
result=cursor.fetchone()
print("\nStored new value:", result[0])
print("Parsed new value:", result[1].isoformat(timespec="milliseconds"))
SQL needed to create the database schema
createtabletest_tz (
test_id number(19),
test_ts timestamp(3) with time zone,
primary key(test_id)
);
insert into test_tz values (1, timestamp'2024-08-04 12:11:13.123');
commit;
The text was updated successfully, but these errors were encountered:
When using timezone aware datetime bind variables, the value passed to the server has the same date/time components as the bind variable but the time zone is changed to UTC regardless of session time zone.
I'm aware that named time zones are not supported, but that change messes up data. imho proper behaviors could be:
I have tested version 2.3.0 of the driver, both thin and thick modes, with 12.2 and 19.13 databases. Running below script in thin mode with a 19.13 database, produces next output
Python script that shows the problem
SQL needed to create the database schema
The text was updated successfully, but these errors were encountered: