Skip to content

Conversation

@educasadei
Copy link
Contributor

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.

@github-actions github-actions bot added the 👀 pr-needs-review PR needs review from a maintainer or community member label Dec 23, 2025
@BuggieBot
Copy link
Member

Hello!

One or more of the commit messages in this PR do not match the SerenityOS code submission policy, please check the lint_commits CI job for more details on which commits were flagged and why.
Please do not close this PR and open another, instead modify your commit message(s) with git commit --amend and force push those changes to update this PR.

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);
Copy link
Contributor Author

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.

Copy link
Member

@LucasChollet LucasChollet left a 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.
@educasadei educasadei force-pushed the outdated-timezone-rules branch from d9690ed to b1943e9 Compare December 24, 2025 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

👀 pr-needs-review PR needs review from a maintainer or community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants