-
Notifications
You must be signed in to change notification settings - Fork 3.3k
LibTimeZone: Improve the handling of outdated timezone rules #26504
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Hello! One or more of the commit messages in this PR do not match the SerenityOS code submission policy, please check the |
AK/Time.h
Outdated
| constexpr Tuple<T, u8, u8> seconds_since_epoch_to_date(T seconds) | ||
| { | ||
| constexpr auto seconds_per_day = 60 * 60 * 24; | ||
| T day_offset_to_epoch = seconds >= 0 ? seconds / seconds_per_day : floor_div(seconds, seconds_per_day); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taken from LibC/time.cpp:150.
LucasChollet
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this!
…o_date() The seconds_since_epoch_to_year() used an innacurate aproximation, causing problems near year boundaries. The new version relies upon the days_since_epoch_to_date() which uses a much better algorithmn.
The previous method simply picked the last rule when all of them were outside the time range, causing the timezone to be permanently in the wrong offset when the last rule didn't have an offset of 0. One of the affected timezones was America/Sao_Paulo, because Brazil's DST rules end in 2019 and its last rule is setting the start of DST for 2018, which (due to the behavior described above) causes the timezone to be stuck in Daylight Saving Time. This surfaced an error in two of the test cases for Europe/Moscow, they were using the incorrect daylight and standard time names for the period being tested.
d9690ed to
b1943e9
Compare
The previous method simply picked the last rule when all of them were outside the time range, causing the timezone to be permanently in the wrong offset when the last rule didn't have an offset of 0.
One of the affected timezones was America/Sao_Paulo, because Brazil's DST rules end in 2019 and its last rule is setting the start of DST for 2018, which (due to the behavior described above) causes the timezone to be stuck in Daylight Saving Time.
This surfaced an error in two of the test cases for Europe/Moscow, they were using the incorrect daylight and standard time names for the period being tested.