CODEWITHSUNDEEP
c#asp.netwindowsdsttimezone-offset
jpe230
jpe230

Reputation: 11

What could cause an incorrect UTC offset when parsing last year ISO string date?

I can't figure why it fails under certain environments.

I have an ASP.NET Web API (.NET Framework 4.8）running under Windows 11 and a SPA as the client. The SPA has a date-picker for filtering some data, the date is sent as an ISO string, so my timezone is sent as part of the hour. Normally this would not be a problem but since the start of the current year (2023) the Mexican government removed the Daylight Saving Time. This caused my WebApi to act weird when dealing with dates with years before 2023.

My SPA outputs the correct offset when getting past years dates.

Example:

var year = 2023;
var month = 9;
var day = 6;
var today = new Date(year, month, day);
console.log(today.toISOString());

year = year - 1; // Get last year date (should apply DST)
var lastYearDate = new Date(year, month, day);
console.log(lastYearDate .toISOString());

The result of the above is:

2023-10-06T06:00:00.000Z // Offset GMT-6
2022-10-06T05:00:00.000Z // Offset GMT-5 w/DST

Notice how it applies correctly the offset when creating dates before 2023.

When parsing the strings using .NET Framework + Windows 11, I get the correct result:

static void PrintDate()
{
   // Current Year no DST (GMT - 6) 
   var isoDate1 = "2023-10-06T06:00:00.000Z";
   var dateTime1 = Convert.ToDateTime(isoDate1);
   var dateToIso1 = dateTime1.ToString("o", System.Globalization.CultureInfo.InvariantCulture);

   // Last year with DST(GMT - 5)
   var isoDate2 = "2022-10-06T05:00:00.000Z";
   var dateTime2 = Convert.ToDateTime(isoDate2);
   var dateToIso2 = dateTime2.ToString("o", System.Globalization.CultureInfo.InvariantCulture);

   Console.WriteLine($"The parsed date is: {dateToIso1}");
   Console.WriteLine($"The parsed date is: {dateToIso2}");
}

And the result is:

The parsed date is: 2023-10-06T00:00:00.0000000-06:00
The parsed date is: 2022-10-06T00:00:00.0000000-05:00

It looks fine in my machine, since .NET is applying correctly the offset, GMT-6 to this year and GMT-5 to the prior year. But when deploying to a Windows Server machine, either 2019 or 2022, I get a different offset.

The result of the Windows Server:

The parsed date is: 2023-10-06T00:00:00.0000000-06:00
The parsed date is: 2022-10-05T23:00:00.0000000-06:00

Notice how it is now applying the wrong offset to the date of 2022, this is causing to roll back one day and giving me the wrong data.

What could cause this behaviour?

I already tried:

Since the removal of the DST is recent, I was ensured by my IT department that the servers already contained the necessary updates to handle the lack of DST. Creating a new VM without those updates resulted in the server having an offset of +1 hour (GMT-5) both in the system clock as well as in the parsing of the dates of the current year.

I would expect that Windows Server/.NET framework would apply the correct offset when using the same time zone regardless of the machine it is running.

Upvotes: 1

Views: 93

Answers (1)

Matt Johnson-Pint
Matt Johnson-Pint

Reputation: 241808

... But when deploying to a Windows Server machine, either 2019 or 2022, I get a different offset.

Then likely you need to apply Windows Updates to the Windows Server machines that are running your code.

... I was ensured by my IT department that the servers already contained the necessary updates ...

Your results prove otherwise. The required updates are not present on the machines you've deployed to. The specific KB articles for Mexico's DST are listed as part of the announcement here. This is from Microsoft's DST/TZ Blog. You may want to pass that along to your IT department.

Upvotes: 1

Related Questions