DateTimeTimeZone ToDateTime returning incorrect parsed date

[chrisportelli]

Describe the bug
We identified an inconsistent behaviour when using the DateTimeTimeZone.ToDateTime() in v4.52.0 of the library across our local and Azure environments. This is used when interacting with the MS Bookings API.

From the Graph API, we are calling GET bookingAppointment to get specific appointments. As part of the response it returns the startDateTime and endDateTime, like below (JSON is reduced for brevity):

{
    "startDateTime": {
        "dateTime": "2024-01-16T07:30:00.0000000Z",
        "timeZone": "UTC"
    }
}

We are using the above ToDateTime() extension method to parse this date as a DateTime object so that we can convert it to CET/CEST, which is the time zone used by the application. However, we are experiencing discrepancies between the returned value of this method for the application running locally (which runs as CET/CEST) and the application deployed to Azure (which runs as UTC).

Taking the above example, when running locally as CET/CEST, when calling the extension method the following happens when debugging the method:

1. DateTime.ParseExact() converts "2024-01-16T07:30:00.0000000Z" (UTC) to "2024-01-16 08:30" (Local Kind)
2. Since the time zone received from the API response is "UTC" in DateTime.SpecifyKind() it returns "2024-01-16 08:30" (UTC Kind)

When returning the result from the extension method, we are then trying to convert this DateTime to a CET/CEST time zone using TimeZoneInfo.ConvertTime() which is leading to the time being "2024-01-16 09:30" which is incorrect, as the original "2024-01-16T07:30:00.0000000Z" should be 08:30 in CET/CEST and not 09:30.

This does not happen of course in the Azure web app as it is using UTC, however, we have a function app where we are using WEBSITE_TIME_ZONE set to "W. Europe Standard Time" and the hours are coming in incorrectly.

Can you let us know if this is an issue with the client library or if we are missing or misunderstanding something about the purpose of this extension method?

To Reproduce
Using the SDK v4.52.0 call the extension method as follows from a machine with a time zone that is not aligned with GMT.

var dateTimeTimeZone = new DateTimeTimeZone
{
    DateTime = "2024-01-16T07:30:00.0000000Z",
    TimeZone = "UTC"
};
var parsedDate = dateTimeTimeZone.ToDateTime();

Expected behavior
The correct time is returned after parsing the DateTimeTimeZone.ToDateTime().

Client version
SDK version 4.52.0 running with .NET 6 (the issue is also replicable in .NET 8 using the same SDK version).

[andrueastman]

Thanks for raising this @chrisportelli,

Taking the above example, when running locally as CET/CEST, when calling the extension method the following happens when debugging the method:

• DateTime.ParseExact() converts "2024-01-16T07:30:00.0000000Z" (UTC) to "2024-01-16 08:30" (Local Kind)
• Since the time zone received from the API response is "UTC" in DateTime.SpecifyKind() it returns "2024-01-16 08:30" (UTC Kind)

I believe this may be incorrect behavior for the extension method given that local DateTime.ParseExact() returns a local time and then changes the Kind to UTC(introducing the extra offset later on) rather than setting the time to UTC. We'll need to validate this.

Any chance you get the correct results if you get the datetime value from the ToDateTimeOffset() method as below?

        var dateTime = dateTimeTimeZone.ToDateTimeOffset().DateTime;// get the datetime value from DateTimeOffset

        TimeZoneInfo timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time");
        var cetTime = TimeZoneInfo.ConvertTime(dateTime, timeZoneInfo);
        var localTime = TimeZoneInfo.ConvertTime(dateTime, TimeZoneInfo.Local);

[chrisportelli]

Thanks @andrueastman for getting back. That works for us. I'm assuming it's because it sets the date's Kind to "Unspecified". Would be nice to have ToDateTime() fixed as it caught us a bit off guard when the API response contained a different time zone than the one expected.