Need the ability to set a time zone per Azure sql database
We need to be able to set the timezone for an Azure sql or DW database. This should be a database option.
Now we are faced with changing all of our code which references getdate() and similar date functions.
We shouldn't have this extra difficulty in moving to a cloud database.
Planned for SQL DB- no time frame to share yet. Available in SQL Managed Instance
Drazen Sumic commented
We understand the functional ask and that is a significant pain point when migrating the app to the cloud. We have added this feature to the plan for the SQL Database Managed Instance, and funded the engineering work on it. The setting planned is at the instance level (set at the instance creation time), which means it would be applied to all time-zone sensitive functionality on the Managed Instance, so getdate() but also other appropriate functions, system views, etc. I can't share a timeline publicly yet.
SQL engineering team.
Raghavendra Narayana commented
I agree, this is extra difficulty. More than changing the code, validation and testing takes time.
For now, I am thinking to create below function and do find & replace Getdate() with udo.Getdate(getdate()) in the code. Let me know any issues or challenges you see OR better alternate available. Note: udo is a schema name I used, it can be anything like dbo or your own schema name. I am adding 4 hours, you need to change this accordingly to your time zone.
CREATE FUNCTION udo.GETDATE (@d datetime) RETURNS DATETIME
RETURN DATEADD(HOUR, 4, @d);
Azure does not have data centers in Africa yet so my code base needs to change now to go live and then again when we migrate later in 2018.
Guess I got too use to Enterprise Solutions
I discovered this limitation after weeks of exploring powerapps and azure sql server as there is now way to modify the default time zone of sql server in azure. This is a definitive blocker because many programs are alsi using the database
Jim Mullennix commented
I agree. This is a major pain for some types of migrations. Some migrations are mandated to be as quick as possible, with minimal code changes. Imagine having to update dozens to hundreds of stored procedures, views, and other SQL statements for an application that is vintage 2008 or earlier that makes heavy use of GETDATE. Every single instance of a datetime field has to be evaluated and updated and tested. This could add weeks to implementation. That could be very expensive.
TimeZone conversion function is handy, but it comes lot of work to change the whole code references which is pain
Érico Silva commented
The AWS RDS SQL service allows you to set timezone for the region where we are. Microsoft is late in implementing this feature. It is very laborious to have to deal with this in the application. The solution should be in the database configuration, just as we have in the on premisse environment. Without this configuration, it is very complicated to take large applications that do not have this treatment into the Microsoft cloud.