To diagnose, we usually need to know the following, including version numbers. On Windows, be
sure to specify 32-bit Python or 64-bit:
Python: 3.11 64-bit
pyodbc: 4.0.35
OS: Windows 10
DB: SQL Server 2019 (15.0.4123.1)
driver: ODBC Driver 18 for SQL Server (2018.181.02.0
ODBC Trace: SQL.LOG
Issue
The timezone is getting lost somewhere when executing the query DECLARE @INPUT DATETIMEOFFSET=?; SELECT @INPUT AS [output] and passing in a datetime with a timezone other than UTC... I think pyodbc isn't sending it correctly, because the timezone comes back as UTC in the handle_datetimeoffset function. (see the test_round_trip_local test)
I'm not sure what's going on under the hood, but I think python datetimes should always be sent as DATETIMEOFFSET to MSSQL when they have the timezone set. No timezone should fallback to DATETIME2.. MSSSQL does implicit conversions of these to DATE/DATETIME so it should be backwards compatible.
Please first make sure you have looked at:
Environment
To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:
Python: 3.11 64-bit pyodbc: 4.0.35 OS: Windows 10 DB: SQL Server 2019 (15.0.4123.1) driver: ODBC Driver 18 for SQL Server (2018.181.02.0 ODBC Trace: SQL.LOG
Issue
The timezone is getting lost somewhere when executing the query
DECLARE @INPUT DATETIMEOFFSET=?; SELECT @INPUT AS [output]
and passing in a datetime with a timezone other than UTC... I think pyodbc isn't sending it correctly, because the timezone comes back as UTC in the handle_datetimeoffset function. (see the test_round_trip_local test)I'm not sure what's going on under the hood, but I think python datetimes should always be sent as DATETIMEOFFSET to MSSQL when they have the timezone set. No timezone should fallback to DATETIME2.. MSSSQL does implicit conversions of these to DATE/DATETIME so it should be backwards compatible.