Yukon Standard Time UTC Offset Issues

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Yukon Standard Time was recently added to the Windows time zone registry and is thus available to use in DotNet. However, we have discovered there are some issues as to its implementation.

Issue 1:
Starting in 2021, the TimeZoneInfo.AdjustmentRule for "Yukon Standard Time" uses an internal BaseUtcOffsetDelta TimeSpan property to adjust the base UTC Offset for Yukon Standard Time. Is there a reason this property is not public and exposed on the TimeZoneInfo.AdjustementRule class?

Otherwise trying to derive the UTC offset of the Yukon Standard Time time zone after Jan 1, 2021 leads to an invalid UTC offset (without using the TimeZoneInfo.GetUtcOffset method) as the BaseUtcOffsetDelta is not taken into account (as its not known). We are currently using reflection to get this property value, as otherwise its hidden with the internal property accessor. For reference, we are exporting the values in the TimeZoneInfo classes to JSON objects to use within a Javascript library (similar to TimeZoneInfo in C#) to do time zones calculations on the browser without making a roundtrip to the server.

Issue 2:
As well, The "Yukon Standard Time" TimeZoneInfo reports the incorrect UTC Offset for the dates between 2021-01-01T00:00:00.000-7:00 and 2021-01-01T00:59:59.999-7:00 (inclusive). Instead of returning -7:00, it returns -8:00.

Tracing through the TimeZoneInfo class code, this appears to be an issue where the previous year's TimeZoneInfo.AdjustmentRule is being used due to the BaseUtcOffsetDelta not being applied until later on (meaning it selects 2020 as the year instead of 2021). Additionally, various edge-cases checks against using the next or previous rule are not being triggered due to the rule being more than one year long. I'm not sure if this is an issue with the rule selection logic, edge case conditions, or the underlying Yukon time zone data itself.

This also appears to affect SQL Server's AT TIME ZONE function, which I assume is implemented in a similar manner.

C# test case that should fail, but passes:

var yukon = TimeZoneInfo.FindSystemTimeZoneById("Yukon Standard Time");
var beforeMidnight = new DateTimeOffset(2020, 12, 31, 23, 59, 59, 999, new TimeSpan(-7, 0, 0));
var midnight = new DateTimeOffset(2021, 1, 1, 0, 0, 0, 0, new TimeSpan(-7, 0, 0));
var before1AM = new DateTimeOffset(2021, 1, 1, 0, 59, 59, 999, new TimeSpan(-7, 0, 0));
var at1AM = new DateTimeOffset(2021, 1, 1, 1, 0, 0, 0, new TimeSpan(-7, 0, 0));
var midnight2022 = new DateTimeOffset(2022, 1, 1, 0, 0, 0, 0, new TimeSpan(-7, 0, 0));
Assert.AreEqual(new TimeSpan(-7, 0, 0), yukon. GetUtcOffset(beforeMidnight), "On date " + beforeMidnight.ToString());

Assert.AreEqual(new TimeSpan(-8, 0, 0), yukon. GetUtcOffset(midnight), "On date " + midnight. ToString()); // This assert should fail, but it doesn't as the wrong offset is returned

Assert.AreEqual(new TimeSpan(-8, 0, 0), yukon. GetUtcOffset(before1AM), "On date " + before1AM.ToString()); // This assert should fail, but it doesn't as the wrong offset is returned

Assert.AreEqual(new TimeSpan(-7, 0, 0), yukon. GetUtcOffset(at1AM), "On date " + at1AM.ToString());

Assert.AreEqual(new TimeSpan(-7, 0, 0), yukon. GetUtcOffset(midnight2022), "On date " + midnight2022. ToString());

---

Original Comments

Feedback Bot on 10/14/2020, 03:33 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

(no solutions)

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[tarekgh]

Is there a reason this property is not public and exposed on the TimeZoneInfo.AdjustementRule class?

We are looking to provide better support for time zones in general and that is why we are not rushing exposing this property which may conflict later with what we may come up with. But in general I am not seeing any strong reason prevent us exposing the UTC offset of every rule (which encapsulate the calculation of the delta and the zone offset).

Otherwise trying to derive the UTC offset of the Yukon Standard Time time zone after Jan 1, 2021 leads to an invalid UTC offset

Let me explain what could be happening here. We read the time zone data from the registry. For this zone, it is has the UTC offset -9 hours because we still in year 2020. That is why when looking at AdjustmentRule of 2021 you will see it has the offset delta be 1 hours as it looks it is decided to change the base offset of the Yukon zone to be -8 hours instead of -9. Because of that, it looks Windows couldn't use -8 for this yet and will wait till 2021 and update the UTC offset data again to be -8 instead of -9. at that time you'll have everything work fine without need to access offset delta.
In general I would recommend not directly using the offsets to do your calculations and instead call GetUtcOffset and make it do it for you.

As well, The "Yukon Standard Time" TimeZoneInfo reports the incorrect UTC Offset for the dates between 2021-01-01T00:00:00.000-7:00 and 2021-01-01T00:59:59.999-7:00 (inclusive). Instead of returning -7:00, it returns -8:00.

This is the side effect of the current data but I agree we have a bug here we can address. If Windows changed the zone UTC offset data later to be -8 instead of -9 when we approach 2021, this this bug will disappear again and everything should work. We''' try to fix this in the next release of .NET core.

For reference, we are exporting the values in the TimeZoneInfo classes to JSON objects to use within a Javascript library (similar to TimeZoneInfo in C#) to do time zones calculations on the browser without making a roundtrip to the server.

are you using .NET Framework or are you using .NET Core? I am asking because although we support and maintain .NET Framework, we are not actively doing any development there. which means any enhancement would be for .NET Core. Also, for Javascript, did you consider to use any TZ javascript library for that instead of the exporting you are doing to JSON objects?

[kchutskoff]

are you using .NET Framework or are you using .NET Core?

Unfortunately we're still using .NET Framework.

Also, for Javascript, did you consider to use any TZ javascript library for that instead of the exporting you are doing to JSON objects?

Yes. We wanted to have a unified source of truth for time zones between all our languages and only wanted to update a single dataset to maintain time zone changes over time. As both C# and SQL Server use the windows registry as their data source (which is also kept updated via windows updates) we felt this was the best approach for our application. We considered directly exporting from the registry to JSON objects, but seeing as how TimeZoneInfo was already parsing the registry data, it was faster and easier to piggyback off it.

Thanks for the information and for looking into it!