How can we improve Azure SQL Database?

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.

276 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Mark shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    14 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Yomi Bazuaye commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        I have now come across this issue and YES We NEED to be able to set a timezone per azure sql database.

      • Mark Freeman commented  ·   ·  Flag as inappropriate

        Implementing this in SQL MI would be helpful. However, we need it in Azure SQL Database as well.

      • Sajith commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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
        AS
        BEGIN
        RETURN DATEADD(HOUR, 4, @d);
        end

      • MJG commented  ·   ·  Flag as inappropriate

        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

      • luis8888 commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        TimeZone conversion function is handy, but it comes lot of work to change the whole code references which is pain

      • Érico Silva commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base