ManagementDateTimeConverter.ToDateTime returns the wrong DateTimeKind

[mattjohnsonpint]

The System.Management.ManagementDateTimeConverter.ToDateTime method is setting DateTimeKind.Unspecified in the result here.

I believe this to be incorrect, as it explicitly adjusts the time to the local computer's offset. As a user of this API, I'd expect the resulting DateTime value's Kind property to be DateTimeKind.Local.

With unspecified kind, I'd expect the result to not have been adjusted to the local time zone.

Also, a couple of other observations about the ManagementDateTimeConverter class:

• The fixes from May 2018 seen in the history don't appear to have been ported back to .NET Framework. For example, I can see that in the NetFX implementation it still uses TimeZone.CurrentTimeZone instead of TimeZoneInfo.Local.

• It would seem prudent to make a ToDateTimeOffset method that retains the offset provided in the DMTF string. Otherwise the user has to go out of their way to parse the string again manually to obtain the original offset.

• Likewise, it would seem prudent to have an overload of ToDMTFDateTime that accepts a DateTimeOffset. Otherwise, there's no capability to create a DMTF string that has anything other than the local offset or zero.

[mattjohnsonpint]

@tarekgh

[tarekgh]

CC @Anipik the area owner.

@mj1856

The docs https://docs.microsoft.com/en-us/dotnet/api/system.management.managementdatetimeconverter.todatetime?view=netframework-4.8 agree with your that the returned DateTime should be in local time zone. I am wondering, does the DateTime reflect that in all its properties except the Kind property? or the the time is not really adjusted to local timezone at all?

The fixes from May 2018 seen in the history don't appear to have been ported back to .NET Framework.

We don't do that except if there is any strong reason. Considering the released 4.8 is the last version of the .NET, I wouldn't expect anything else can be ported there.

It would seem prudent to make a ToDateTimeOffset method that retains the offset provided in the DMTF string. Otherwise the user has to go out of their way to parse the string again manually to obtain the original offset.
Likewise, it would seem prudent to have an overload of ToDMTFDateTime that accepts a DateTimeOffset. Otherwise, there's no capability to create a DMTF string that has anything other than the local offset or zero.

If you have any new API suggestion, feel free to open new issue proposing the new APIs. follow the doc https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md for doing that.
Thanks for your report.

[mattjohnsonpint]

I am wondering, does the DateTime reflect that in all its properties except the Kind property? or the the time is not really adjusted to local timezone at all?

Yes. All of the properties except the Kind are correct, as it manually subtracts the offset.

Now that I look at it again, there's also a subtle hidden bug here, in the call to TimeZoneInfo.Local.GetUtcOffset(datetime). The datetime passed in is constructed with the fields of the input value, so it's looking up the offset based on the wrong point in time. (The input value is not guaranteed to be in local time).

It would be simpler and more correct if the implementation simply constructed a DateTimeOffset from the input values, then returned its LocalDateTime property.