microsoft/Tx

PerformanceSample has local time, but Kind is DateTimeKind.Utc

pbolduc opened this issue · 8 comments

On commit 49369b4 when the TImeUtil.cs was removed, the returned timestamp appears to be incorrect. The dates are local date/times to based on the time zone the machine is running on, however, the Timestamp.Kind == DateTimeKind.Utc

PerfCounterFileReader.cs

DateTime timestamp = DateTime.FromFileTimeUtc(time);
                                          ^^^

The docs for PdhCollectQueryDataWithTime says:

pllTimeStamp [out]
Time stamp when the first counter value in the query was retrieved. The time is specified as FILETIME.

This is also a problem with: PerfCounterRealTimeProbe.cs.

EtwNativeEvent.cs and BondTypeMap.cs also call DateTime.FromFileTimeUtc() but I haven't looked into what those FILETIMEs are supposed to be.

After looking at the source for DateTime.FromFileTime(long) and DateTime.FromFileTImeUtc(long), it seems nether is correct. The FILETIME returned is a local time, and you want a the kind to be DateTimeKind.Local.

I think you need to use a copy of the CLR FromFileTimeUtc(long). Below is taken from FromFileTimeUtc(long), but the last line has DateTimeKind.Utc changed to DateTimeKind.Local

    public static DateTime FromFileTimeLocal(long fileTime)
    {
        if (fileTime < (long)0 || fileTime > 2650467743999999999L)
        {
            throw new ArgumentOutOfRangeException("fileTime", Environment.GetResourceString("ArgumentOutOfRange_FileTimeInvalid"));
        }
        return new DateTime(fileTime + 504911232000000000L, DateTimeKind.Local);
    }

At least the Timestamp will be correct. Leave it up to the user to convert to UTC if they need UTC.

Thanks for reporting that one, Phil, I am going to take a look.

First of all that commit you are referring to did not make any changes, previously the kind was also UTC.

I believe that filetime is local to the machine where the blg file was written, not to the machine there that blg is being parsed. So with the proposed changes the result will not be accurate.

I have created a very simple sample program in a branch in my fork.

https://github.com/pbolduc/Tx/blob/issue-2/Samples/Issue2-demo/Program.cs

The program is pretty simple, read real time performance counter data and display it. The screen shot below shows that the counter sample is showing local time (I am in Canada/Pacific) but the the kind is set to UTC.

tx-issue

I tried to look at the source to point out where I thought the error was. By your response I must of been way off. Regardless, I would expect the time on a performance counter sample to reflect the correct date and time regardless of in UTC or local time.

That is correct, Phil, that real time feed it is a something that we will fix for sure.

But for the issue related to parsing of blg files, I am still looking if there is a way to get timezone offset information from it using PDH.

It would be great if the BLG parsing woud be correct too. However, my original issue was only meant to cover the real time. Perhaps, a separate issue could be created to track the BLG parsing. Sorry if my first message on this issue mis-directed your attention.

Fixed for both performance counter sources is ready and will be published soon.

The issue has been fixed. Please update your code to use 1.0.51006 version of Tx.Windows package.