FIX: Updates TimeZone support for DATETIMEOFFSET type, fixes incorrect Now() in USE_TZ=True cases.

[trolldbois]

1. handle_datetimeoffset Fixes the datetime parsing of column type DATETIMEOFFSET. This updates Pull Add TimeZone support #140 that forgot to parse the timezone offset part of the type. This is a straightforward bugfix. (see Datetimeoffset support ? #136 )

2. sqlserver_now Fixes Now(), to use timezone-aware SYSDATETIMEOFFSET(), to ensure a timezone aware (USE_TZ) django get a correct value for Now() when the database OS is not configured as UTC timezone.

This also fixes #371 .

[trolldbois]

@microsoft-github-policy-service agree

[trolldbois]

An explainer for fix 2. sqlserver_now
If you have a model that uses auto_now or auto_now_add the database value of that field will use the SQL server's Now() function. Using Now=SYSDATETIME() returns a timezone deficient value, with the database OS's local time (So lets say time in Africa/Nairobi +03:00).
But with settings.USE_TZ=True, django will parse this timezone-deficient value, and incorrectly replace the empty timezone offset (tzinfo) with the default django UTC offset (00:00) instead of the offset that the OS's system timezone used (+03:00).
So previous to this fix, all usage of Now(), for database OS not using UTC as system timezone, have stored a localtime, that is incorrectly parsed back by django as UTC. In this example, Now() would be parsed back by django as a datetime 3 hours in the future.
By using Now=SYSDATETIMEOFFSET(), we allow the storage of the timezone offset in DATETIMEOFFSET columns, whereas for DATETIME2 columns, the offset is truncated by sql server, and the value remains the same as SYSDATETIME().
With the addition of the handle_datetimeoffset bugfix, django will parse back a datetime with the correct timezone information, and now becomes the present, once again.

Notably, if your model still use a DATETIME2 column, and the Database timezone is not UTC, you will still experience a bug when using Now() or a model with auto_now, auto_now_add , unless you set your django database setting to the correct TIME_ZONE. But then you will experience other issues when USE_TZ=True . Logically, DATETIME2 is not compatible with USE_TZ=True when the SQL Server OS is using a timezone that is not UTC. See https://github.com/microsoft/mssql-django/wiki/Timezone-Support for migration.

[Copilot]

Pull request overview

This PR improves timezone correctness in the SQL Server backend by (1) decoding DATETIMEOFFSET values into timezone-aware Python datetimes (including the stored offset) and (2) updating the SQL emitted for Django’s Now() so tz-aware projects don’t receive misleading “local time treated as UTC” results.

Changes:

• Parse DATETIMEOFFSET binary values into datetime objects with a tzinfo derived from the stored offset.
• Emit SYSDATETIMEOFFSET() for Now() when settings.USE_TZ=True (and keep SYSDATETIME() otherwise).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
mssql/base.py	Extends handle_datetimeoffset() to include timezone offset when constructing Python datetime values.
mssql/functions.py	Updates Now() SQL generation to use SYSDATETIMEOFFSET() under USE_TZ.

[bewithgaurav]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[bewithgaurav]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[bewithgaurav]

@trolldbois - thanks a lot for raising this PR
I've added a few tests and merged this off - thanks again! :)