TimeZone Offset is incorrect for "Egypt Standard Time" on Windows 10

I am trying to convert an UTC date to "Egypt Standard Time", but calculated offset for summer time is different depending on the operating system version:

on windows 10, the offset is +2
on windows 11, the offset is +3 (this is the correct one)

This is the code that I'm using for the conversion:

TimeZoneInfo timeZone = TZConvert.GetTimeZoneInfo("Egypt Standard Time");
DateTimeOffset initialLocalTime = TimeZoneInfo.ConvertTime(dateTimeUtc, timeZone);

dateTimeUtc is of type DateTimeOffset, with value:

    {10/14/2023 9:00:00 PM +00:00}
    Date: {10/14/2023 12:00:00 AM}
    DateTime: {10/14/2023 9:00:00 PM}
    Day: 14
    DayOfWeek: Saturday
    DayOfYear: 287
    Hour: 21
    LocalDateTime: {10/15/2023 12:00:00 AM}
    Millisecond: 0
    Minute: 0
    Month: 10
    Offset: {00:00:00}
    Second: 0
    Ticks: 638329140000000000
    TimeOfDay: {21:00:00}
    UtcDateTime: {10/14/2023 9:00:00 PM}
    UtcTicks: 638329140000000000
    Year: 2023

And this is the result:

{10/14/2023 11:00:00 PM +02:00}
Date: {10/14/2023 12:00:00 AM}
DateTime: {10/14/2023 11:00:00 PM}
Day: 14
DayOfWeek: Saturday
DayOfYear: 287
Hour: 23
LocalDateTime: {10/15/2023 12:00:00 AM}
Millisecond: 0
Minute: 0
Month: 10
Offset: {02:00:00}
Second: 0
Ticks: 638329212000000000
TimeOfDay: {23:00:00}
UtcDateTime: {10/14/2023 9:00:00 PM}
UtcTicks: 638329140000000000
Year: 2023

In the result, the offset is +2 and should be +3.

I found that Daylight saving time in Egypt was changed recently and I assume that tis is the reason why is not working properly on Windows 10.

How can I calculate correctly the Offset for this timeZone on all operating systems? Should I call some external service in order to get the correct offset?

Solution

As Sweeper and Fildor mentioned in comments, the issue is not related to the OS version, but is because one machine has applied the correct Windows Update and the other machine has not.

When a government makes changes to its rules for time zones (including standard time, daylight saving time, and the transitions between), Microsoft issues updates to Windows to account for the change. Ideally, all computers are receiving Windows Updates automatically. If not, then they would not be able to know what change the government has made.

When using TimeZoneInfo in .NET, the time zone data is taken from the underlying operating system. On Windows, that means .NET is impacted by these time zone updates delivered through Windows Update. A similar situation is true for MacOS and Linux, but the updates stem from the IANA tz database rather than Microsoft.

So, to answer your question directly - apply the latest Windows Updates (or the specific KB's mentioned in the announcement blog post), to the machine that's getting the wrong time zone offset, and it will resolve the problem.

As an alternative approach, you can consider writing your application such that you are in control of the time zone data rather than the operating system. The best way to do that in .NET is to use the Noda Time library. See Updating the time zone database in that library's documentation. If you take this approach, then you would need to periodically get a new NodaZoneData file and apply it to your application. You could do that as you build updated versions of your application, or your application could self-contain the logic for fetching time zone data. Either way, the implementation is up to you.