I was looking at data from a customer, in a different time zone (UTC+1) from mine, this week involving SQL Server AlwaysOn (HADRON) and found that lining up the timestamps in the various logs was challenging.   Some times are local to the SQL Server instance, others UTC and yet other utilities attempt to adjust the UTC time using your current client settings.  

I found it helpful to build a table for what each log captures to help me understand the flow of the issue.

For this table assume local time is UTC+1 and my client is UTC-6.

Log/Location Units Example
Cluster Log (Line Header) - Yellow Below UTC 05:34:56.019
Cluster Log (AlwaysOn Message Text with embedded time) - Green Below Local time from GetDate() of the SQL Server instance 06:34:56.019
XEL Timestamp Column UTC adjusted for your clients time zone.  In my case UTC-6 with Daylight Saving Time (DST) enabled 00:34:56.019
XEL Create Time AlwaysOn - Event Data Column Local time from GetDate() of the SQL Server instance 06:34:56.019
SQL Server Error Log Local time from GetDate() of the SQL Server instance 06:34:56.019
Windows Event Logs (Captured on system to TXT) Local time of the customer system 06:34:56.019
Performance Monitor Capture Windows 8 Client - UTC
Windows 2008 R2 Client - UTC
05:34:56.019
Captured Mini/Dump File Current client time zone setting 00:34:56.019
SQL Agent Log Local time of the customer system 06:34:56.019
SQL Profiler Event Display Local time from GetDate() of the SQL Server instance 06:34:56.019
sys.fn_xe_file_target_read_file Event data timestamp data is UTC 05:34:56.019
Reporting Services - Trace Log Local server time 06:34:56.019
Reporting Services - HTTP Log UTC 05:34:56.019
Reporting Services - Execution Log Local Server time 06:34:56.019
Analysis Services - Profile Trace Local Server Time 06:34:56.019
Analysis Services - Server Log Local Server Time 06:34:56.019
SharePoint ULS Log Local Server Time 06:34:56.019

Note: Based on SQL Server 2008 R2 and SQL Server 2012, Windows 2008 R2 and Windows 8

Example of the cluster log, AlwaysOn entry

000015ec.00002a64::2012/09/06-05:34:56.019 INFO  [RES] SQL Server Availability Group: [hadrag] SQL Server component 'query_processing' health state has been changed from 'warning' to 'clean' at 2012-09-06 06:34:56.017

Example setting with my client time zone set to the same time zone as the customers (UTC+1) and restarting SQL Server Management Studio (SSMS) to show matching timestamp adjustment. Without the client adjustment the XEL display shows me 00:34:56.019 for my UTC-6 client settings.

image

Example output when I open the dump file on my client using UTC-6 setting with DST enabled.

Debug session time: Thu Sep  6 00:34:56.019 2012 (UTC - 5:00)

Example Output of a SQL Error log entry and matching .TRC entry

2012-09-06 06:35:37.05 spid478     The client was unable to reuse a session with SPID 478, which had been reset for connection pooling. The failure ID is 29. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

image

 

As you might imagine: I have filed several work items to consolidate the times across this matrix of data points to make it easier to troubleshoot issues.

Bob Dorr - Principal SQL Server Escalation Engineer
assisted by Adam Saxton for (RS, AS and SharePoint)