Azure SQL has literally zero support for database-level locale or time zone options.This isn't true, you can set the database collation when creating a database. Or are you referring specifically to the language of SQL informational responses (such as error messages)?
There is no recourse. There's no setting. There is no way to fix this.
Well, the fix is documented quite explicitly in the developer documentation (https://docs.microsoft.com/en-us/sql/t-sql/functions/getdate...), which of course isn't the place where an administrator would look:
> Azure SQL Database (with the exception of Azure SQL Managed Instance) and Azure Synapse Analytics follow UTC. Use AT TIME ZONE in Azure SQL Database or Azure Synapse Analytics if you need to interpret date and time information in a non-UTC time zone.
Note the addition with the exception of Azure SQL Managed Instance: if you need server-level control over the time zone, you should use a Managed Instance.
As an aside, this problem with datetime fields depending on the server's timezone isn't just a problem in Azure. We've had countless joys with a naive on-prem CRM application storing birthdays in a datetime-field with 00:00:00 as the time part. When we switched to daylight savings time, all those people were suddenly born at 23:00 the day before. Try explaining that one to your users, who (of course) only see the date part in their UI.
This isn't true, you can set the database collation when creating a database. Or are you referring specifically to the language of SQL informational responses (such as error messages)?
There is no recourse. There's no setting. There is no way to fix this.
Well, the fix is documented quite explicitly in the developer documentation (https://docs.microsoft.com/en-us/sql/t-sql/functions/getdate...), which of course isn't the place where an administrator would look:
> Azure SQL Database (with the exception of Azure SQL Managed Instance) and Azure Synapse Analytics follow UTC. Use AT TIME ZONE in Azure SQL Database or Azure Synapse Analytics if you need to interpret date and time information in a non-UTC time zone.
Note the addition with the exception of Azure SQL Managed Instance: if you need server-level control over the time zone, you should use a Managed Instance.
As an aside, this problem with datetime fields depending on the server's timezone isn't just a problem in Azure. We've had countless joys with a naive on-prem CRM application storing birthdays in a datetime-field with 00:00:00 as the time part. When we switched to daylight savings time, all those people were suddenly born at 23:00 the day before. Try explaining that one to your users, who (of course) only see the date part in their UI.