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 MI – no time frame to share yet.
Hitesh Patel commented
Do we have any update on Time Zone setting for Managed Instance?
Marc L. Allen commented
Any update on this? I've gotten all excited about SQL MI, carefully combed through the limitations (didn't see any timezone issue), sold my company, created a test host, started testing, and BOOM!
Please, please, don't make me build up a SQL clustered set.
Any plans to include this function for SQL Logical Server and Pools?
Hi, I won't be original, but... Any updates on ETA yet?
Bill Hodder commented
Any update on this? GA for SQL MI is only a few weeks away....
Tomasz K commented
Managed instances in preview (as per https://docs.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-transact-sql-information ) " GETDATE() and other built-in date/time functions always returns time in UTC time zone. See GETDATE". This will be available in GA?
Yomi Bazuaye commented
Glad to hear that this feature has been added to the backlog. In my opinion this feature should have been available out of the box.
At this point in time (Late Aug 2018) can anyone from the SQL engineering team give an ETA for the availability of this feature?
Danny Lankar commented
I have now come across this issue and YES We NEED to be able to set a timezone per azure sql database.
Joe Rather commented
I agree with Mark. We need this in PaaS as well as IaaS.
Mark Freeman commented
Implementing this in SQL MI would be helpful. However, we need it in Azure SQL Database as well.
We moved our db to paas with lot of expectation , and we moved back all our instances to iaas because of the timezone issue. And, this is not mentioned in Limitation documentation https://docs.microsoft.com/en-us/azure/postgresql/concepts-limits .Though application layer maintain the required timezone for those queries pass through , big application like ours uses many reports which fire direct db queries, sometime we import data directly to staging tables , support team executes all basic queries against time.
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.