Converted GETUTCDATETIME() to SYSDATETIME()

[rahulreddy15]

This PR corrects a critical time zone issue where MSSQLTopSlowQueries and ExecutionPlanQuery were using GETUTCDATE() to filter against qs.last_execution_time, which is stored in server local time. The mismatch caused queries to return no recent data in environments where local time is ahead of UTC.

Replace GETUTCDATE() with SYSDATETIME() in both query time filters to align with the sys.dm_exec_query_stats DMV's local time storage

Integration tests running against SQL Server instances in different time zones will validate that recent slow queries and execution plans are now properly collected within the specified interval window. No additional tests are needed IMO.

[sairaj18]

Could you update the description of the PR with details of why this change is needed?

[sairaj18]

Thanks for updating the PR description.

Integration tests running against SQL Server instances in different time zones will validate that recent slow queries and execution plans are now properly collected within the specified interval window. No additional tests are needed IMO.

If Integration tests are working now. Shouldn't they have failed earlier because we were using UTC time to retrieve recent executed queries?

[nravada]

LGTm

[abhinav1602]

https://learn.microsoft.com/en-us/sql/t-sql/functions/getutcdate-transact-sql?view=sql-server-ver17

I don't think this will work directly for all the cases.

[rahulreddy15]

Answered this in the comment with

The absolute timezone doesn't affect the relative time calculations, and both SYSDATETIME() and last_execution_time always operate in the same timezone context

[abhinav1602]

This PR corrects a critical time zone issue where MSSQLTopSlowQueries and ExecutionPlanQuery were using GETUTCDATE() to filter against qs.last_execution_time, which is stored in server local time. The mismatch caused queries to return no recent data in environments where local time is ahead of UTC.

Replace GETUTCDATE() with SYSDATETIME() in both query time filters to align with the sys.dm_exec_query_stats DMV's local time storage

Integration tests running against SQL Server instances in different time zones will validate that recent slow queries and execution plans are now properly collected within the specified interval window. No additional tests are needed IMO.

last_execution_time	datetime	Last time at which the plan started executing. The time is recorded in the current timezone

as per this doc, the time zone is always set to UTC so I am not sure if this fix will work for all the cases. Is it tested to be working for all the environment types?

[rahulreddy15]

SQL Server (On-Host):

SYSDATETIME() returns the system datetime based on the server's local timezone
Can be configured to any timezone via Windows settings
No built-in UTC awareness in SYSDATETIME()

Azure SQL Managed Instance:

SYSDATETIME() returns datetime in UTC timezone by default
Microsoft documentation states: "Azure SQL Managed Instance uses UTC time zone"
Cannot change the system timezone like on-premises SQL Server

The sys.dm_exec_query_stats.last_execution_time column stores timestamps in the same timezone as the server.
This means local server time in on host sql server and UTC in managed instance.
Refer: https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/timezones-overview?view=azuresql

So for managed instances:
If instance is configured as UTC: Both SYSDATETIME() and last_execution_time use UTC
And for any other timezone for example JST: Both SYSDATETIME() and last_execution_time use JST
So using SYSDATETIME() is the proper solution.

The absolute timezone doesn't affect the relative time calculations, and both SYSDATETIME() and last_execution_time always operate in the same timezone context.

[nravada]

LGTM