Merge pull request #87246 from MladjoA/patch-2

Remove known issue with time zone + PITR

Author: PRMerger15

articles/sql-database/sql-database-managed-instance-timezone.md

@@ -9,7 +9,7 @@ ms.topic: conceptual
 author: MladjoA
 ms.author: mlandzic
 ms.reviewer: 
-ms.date: 08/14/2019
+ms.date: 09/03/2019
 ---
 # Time zones in Azure SQL Database Managed Instance
 
@@ -77,38 +77,20 @@ You can restore a backup file or import data to a managed instance from an insta
 
 ### Point-in-time restore
 
-<del>When you perform a point-in-time restore, the time to restore to is interpreted as UTC time. This way any ambiguities due to daylight saving time and its potential changes are avoided.<del>
-
- >[!WARNING]
-  > Current behavior is not in line with the statement above, and time to restore to is interpreted as per the time zone of the source managed instance where automatic database backups are taken from. We are working on correcting this behavior to interpret given point in time as UTC time.
+When you perform a point-in-time restore, the time to restore to is interpreted as UTC time. This way any ambiguities due to daylight saving time and its potential changes are avoided.
 
 ### Auto-failover groups
 
 Using the same time zone across a primary and secondary instance in a failover group isn't enforced, but we strongly recommend it.
 
   >[!WARNING]
-  > We strongly recommend that you use the same time zone for the primary and secondary instance in a failover group. Because of some rare scenarios, keeping the same time zone across primary and secondary instances isn't enforced. It's important to understand that in the case of manual or automatic failover, the secondary instance will retain its original time zone.
+  > We strongly recommend that you use the same time zone for the primary and secondary instance in a failover group. Because of certain rare use cases keeping the same time zone across primary and secondary instances isn't enforced. It's important to understand that in the case of manual or automatic failover, the secondary instance will retain its original time zone.
 
 ## Limitations
 
 - The time zone of the existing managed instance can't be changed.
 - External processes launched from the SQL Server Agent jobs don't observe the time zone of the instance.
 
-## Known issues
-
-When point-in-time restore (PITR) operation is performed, the time to restore to is interpreted as per time zone set on the managed instance where automatic database backups are taken from, even though portal page for PITR suggests that the time is interpreted as UTC.
-
-Example:
-
-Say that instance where automatic backups are taken from has Eastern Standard Time (UTC-5) time zone set.
-Portal page for point-in-time restore suggests that the time you are choosing to restore to is UTC time:
-
-![PITR with local time using portal](media/sql-database-managed-instance-timezone/02-pitr-with-nonutc-timezone.png)
-
-However, the time to restore to is actually interpreted as Eastern Standard Time, and in this specific example database will be restored to the state at 9 AM Eastern Standard Time, and not UTC time.
-
-If you want to do point-in-time restore to a specific point in UTC time, first calculate equivalent time in the time zone of the source instance and use that time in the portal or PowerShell/CLI script.
-
 ## List of supported time zones
 
 | **Time zone ID** | **Time zone display name** |