Fix Fiji time zone time conversion

[tarekgh]

This change fixes the time conversion for the Fiji time zone when running on Windows. In this time zone, the time reported during last hour of 2022/12/31 will be off by one hour. This time zone is supposed to be in DST period which should be UTC+13. But we report this time as standard time as UTC+12. This problem started to show up after Windows updated the time zone data.

More Details

Windows time zone data have rules for different years. The rule for any year contains the date and time when the DST period starts and when it ends. In some non-mainstream cases, Windows uses a specific time stamp Jan 1st 12:00 AM inside the rule. This time stamp can be assigned to DST start to tell the year already starts with DST on. Also, it assigns the timestamp to the DST end to tell this year will end while the DST is on. When converting any UTC time to the local time, we use the rule to know when the DST starts and when ends to know if we need to apply the time shift during the DST period or not. When encountering rules has the special case of Jan 1st 12:00 AM timestamp, if this time stamp applied to the start of the DST period, we'll try to get when the DST started by accessing previous year rule. If the timestamp applied to the DST end period, we'll try to know when the DST is ended by accessing the next year rule. We do that because UTC time in specific year can span another year in the local time. Everything was already handled in the code for regular time zone which has the DST start date is before the DST end date. But for southern sphere time zones (like Fiji time zone), Windows data can contain the DST start date be after DST end date because seasons are flipped compared to the northern sphere. We were not handling southern sphere time zone correctly when any of its rules marked with Jan 1st 12:00 AM timestamp and the change in the PR is fixing this case.

[ghost]

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

[ghost]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This change fixes the time conversion for the Fiji time zone when running on Windows. In this time zone, the time reported during last hour of 2022/12/31 will be off by one hour. This time zone is supposed to be in DST period which should be UTC+13. But we report this time as standard time as UTC+12. This problem started to show up after Windows updated the time zone data.

More Details

Windows time zone data have rules for different years. The rule for any year contains the date and time when the DST period starts and when it ends. In some non-mainstream cases, Windows uses a specific time stamp Jan 1st 12:00 AM inside the rule. This time stamp can be assigned to DST start to tell the year already starts with DST on. Also, it assigns the timestamp to the DST end to tell this year will end while the DST is on. When converting any UTC time to the local time, we use the rule to know when the DST starts and when ends to know if we need to apply the time shift during the DST period or not. When encountering rules has the special case of Jan 1st 12:00 AM timestamp, if this time stamp applied to the start of the DST period, we'll try to get when the DST started by accessing previous year rule. If the timestamp applied to the DST end period, we'll try to know when the DST is ended by accessing the next year rule. We do that because UTC time in specific year can span another year in the local time. Everything was already handled in the code for regular time zone which has the DST start date is before the DST end date. But for southern sphere time zones (like Fiji time zone), Windows data can contain the DST start date be after DST end date because seasons are flipped compared to the northern sphere. We were not handling southern sphere time zone correctly when any of its rules marked with Jan 1st 12:00 AM timestamp and the change in the PR is fixing this case.

Author:	tarekgh
Assignees:	tarekgh
Labels:	area-System.Runtime
Milestone:	-

[eerhardt]

This looks good to me. Thanks!