Datetimeoffset values retain original offset causing cross‑region query mismatch
0 reputation · 05 Sept 2021, 16:35 UTC
Goal
Ensure that datetime values retrieved from Azure SQL Database are interpreted consistently across application instances deployed in different Azure regions, without requiring each client to apply custom logic.
Constraints and uncertainty
Azure SQL Database stores datetimeoffset values with the original time‑zone offset and returns them unchanged on SELECT; there is no server‑side automatic conversion to UTC or a target zone. Developers must use the AT TIME ZONE expression (available from SQL Server 2016) to normalize values, but it is unclear whether applying this expression per row introduces noticeable overhead or whether a schema‑level solution (e.g., computed column) is preferable.
What is the recommended strategy for achieving UTC‑normalized results in cross‑region scenarios?
Does using AT TIME ZONE on large result sets affect query performance compared to storing UTC‑only datetime2 columns?
Can a persisted computed column with AT TIME ZONE be used to provide a normalized view without altering existing INSERT logic?
