2018.4: Fix Incorrect UTC offset during DST transition (case 1288231) #1375
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a datetime appears in range of [end_of_DST_period - Daylight_delta; end_of_DST_period] it's not DST and should return base offset. Fixes mono#9664.
Addresses an issue with jumping into DST for some time zones when the incorrect date-time offset is returned for date-time in UTC (which comes from DateTime.Now). The fix is to just check if the incoming date-time is in UTC. Also added a set of tests for some time zones to verify jumping into DST in general. Fixes mono#16395
Corrects an issue where for the hour after the DST transition, the local UTC offset was listed. The UTC offset was the DST offset instead of the standard time offset. The runtime library captures this an ambiguous time. That is the local time that occurs twice - once in DST then once in standard time. If DST is an extra 1:00 a.m. offset and ends at 2:00 a.m., 1:00 a.m. to 1:59:59.9999.... occurs twice. First in DST then again in standard time. The classlibs had this incorrect - they did not consider 1:00 a.m. an ambiguous time, and considered 2:00 a.m. ambiguous. However it should be reversed. 1:00 a.m. occurs twice, but 2:00 a.m. only occurs once. The instance we would hit 2:00 a.m. DST, we instantaneous switch to 1:00 a.m. standard. The classlibs were also not recording enough information to record which side of DST a local time was. When converting a time from UTC, or using DateTime.Now an internal flag, IsAmbiguousDaylightSavingTime, should be set if the time is an ambiguous local time that is on the DST side of the transition. The classlibs were calling TimeZone.IsAmbigousTime which has a wider defintion for ambiguous time that the IsAmbiguousDaylightSavingTime should have. It returns true for local times on either side of DST. So a new method IsAmbiguousLocalDstFromUtc was added to check this case. The classlibs were also not checking the IsAmbiguousLocalDstFromUtc flag when getting the UTC offset for a local time. So a check was inserted in two locations to correct for that. Some tests has to be updated to reflect these new definitions of when DST starts and ends and which times are ambiguous. These also account for some test changes required by cherry-picked changes to TimeZoneInfo.cs where the corresponding test changes were not cherry-picked. Some of those changes where in PR's that updated to the CoreFx TimeZoneInfo class. All these changes have been verified against the behavior of the .Net Framework and they match. Fix case 1288231: Mono: Fix incorrect UTC offset during daylight savings time transitions
Collaborator
|
|
jhcdunity3d
approved these changes
Dec 28, 2020
scott-ferguson-unity
approved these changes
Jan 6, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Corrects an issue where for the hour after the DST transition, the
local UTC offset was listed. The UTC offset was the DST offset
instead of the standard time offset.
The runtime library captures this an ambiguous time. That is
the local time that occurs twice - once in DST then once in standard
time. If DST is an extra 1:00 a.m. offset and ends at 2:00 a.m., 1:00 a.m.
to 1:59:59.9999.... occurs twice. First in DST then again in standard
time.
The classlibs had this incorrect - they did not consider 1:00 a.m. an
ambiguous time, and considered 2:00 a.m. ambiguous. However it should
be reversed. 1:00 a.m. occurs twice, but 2:00 a.m. only occurs once.
The instance we would hit 2:00 a.m. DST, we instantaneous switch to
1:00 a.m. standard.
The classlibs were also not recording enough information to record
which side of DST a local time was. When converting a time from UTC,
or using DateTime.Now an internal flag, IsAmbiguousDaylightSavingTime,
should be set if the time is an ambiguous local time that is on the
DST side of the transition. The classlibs were calling
TimeZone.IsAmbigousTime which has a wider defintion for ambiguous
time that the IsAmbiguousDaylightSavingTime should have. It returns
true for local times on either side of DST. So a new method
IsAmbiguousLocalDstFromUtc was added to check this case.
The classlibs were also not checking the IsAmbiguousLocalDstFromUtc
flag when getting the UTC offset for a local time. So a check
was inserted in two locations to correct for that.
Some tests has to be updated to reflect these new definitions of when
DST starts and ends and which times are ambiguous. These also account
for some test changes required by cherry-picked changes to
TimeZoneInfo.cs where the corresponding test changes were not
cherry-picked. Some of those changes where in PR's that updated to
the CoreFx TimeZoneInfo class.
All these changes have been verified against the behavior of the
.Net Framework and they match.
Fix case 1288231:
Mono: Fix incorrect UTC offset during daylight savings time transitions