Skip to content
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

"Repeat every X weeks" is broken in certain time zones #408

Open
7 tasks done
tom93 opened this issue Jan 4, 2025 · 0 comments · May be fixed by #409
Open
7 tasks done

"Repeat every X weeks" is broken in certain time zones #408

tom93 opened this issue Jan 4, 2025 · 0 comments · May be fixed by #409
Labels
bug Something is not working

Comments

@tom93
Copy link

tom93 commented Jan 4, 2025

Proposed fix: #409

Checklist

  • I can reproduce the bug with the latest version given here.
  • I made sure that there are no existing issues - open or closed - to which I could contribute my information.
  • I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
  • I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
  • I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
  • This issue contains only one bug.
  • I have read and understood the contribution guidelines.

Affected app version

1.1.0

Affected Android/Custom ROM version

Android 14

Affected device model

Emulator

How did you install the app?

GitHub releases

Steps to reproduce the bug

  1. Set the time zone to Antarctica/McMurdo
  2. Create an event on Monday 11 March 2024 at 9am with custom repetition every 3 weeks
  3. View the occurrences of the event

Expected behavior

The occurrences should be:
Mon 11 Mar 2024
Mon 01 Apr 2024
Mon 22 Apr 2024
Mon 13 May 2024

Actual behavior

The occurrences are:
Mon 11 Mar 2024
Mon 01 Apr 2024
Mon 15 Apr 2024 (incorrect -- gap is 2 weeks instead of 3)
Mon 06 May 2024

Screenshots/Screen recordings

1-set-time-zone 2-event-details 3-occurrences-march 4-occurrences-april

Observe how in the final screenshot (April) the occurrences are incorrect.

Analysis

The bug is in the method isOnProperWeek in models/Event.k.

It calculates the week number of a timestamp by taking the start-of-day (in the default time zone) as a Unix timestamp then dividing by 7 weeks and rounding to the nearest integer. This works in most cases, but is actually wrong. It mostly works because:

  • The Unix epoch is Thursday 00:00 UTC.
  • So timestamps within 3.5 days of Thu 00:00 UTC are rounded to the same week number.
  • So the threshold is Sunday 12:00 UTC.
  • In most time zones, the start-of-day of Sunday is before Sunday 12:00 UTC, and the start-of-day of Monday is after Sunday 12:00 UTC. So in most time zones the calculation assigns the same week number to Mon-Sun.

However, this breaks in time zones such as Antarctica/McMurdo, because in that time zone the start-of-day of Monday is very close to Sunday 12:00 UTC, so the rounding is unstable, and daylight saving causes the calculation to produce an incorrect week number.

@tom93 tom93 added bug Something is not working needs triage Issue is not yet ready for PR authors to take up labels Jan 4, 2025
tom93 added a commit to tom93/Calendar that referenced this issue Jan 4, 2025
The previous implementation was broken on some time zones (see FossifyOrg#408
for details).

The new implementation hard-codes the start of the week to be Monday
to match the previous behaviour. Ideally this should be configurable
(see the TODO comment for more notes).

Fixes FossifyOrg#408.
@tom93 tom93 linked a pull request Jan 4, 2025 that will close this issue
4 tasks
tom93 added a commit to tom93/Calendar that referenced this issue Jan 4, 2025
The previous implementation was broken in some time zones (see FossifyOrg#408
for details).

The new implementation hard-codes the start of the week to be Monday
to match the previous behaviour. Ideally this should be configurable
(see the TODO comment for more notes).

Fixes FossifyOrg#408.
@Aga-C Aga-C removed the needs triage Issue is not yet ready for PR authors to take up label Jan 4, 2025
tom93 added a commit to tom93/Calendar that referenced this issue Jan 16, 2025
The previous implementation was broken in some time zones (see FossifyOrg#408
for details).

The new implementation hard-codes the start of the week to be Monday
to match the previous behaviour. Ideally this should be configurable
(see the TODO comment for more notes).

Fixes FossifyOrg#408.
tom93 added a commit to tom93/Calendar that referenced this issue Jan 18, 2025
The previous implementation was broken in some time zones (see FossifyOrg#408
for details).

The new implementation hard-codes the start of the week to be Monday
to match the previous behaviour. Ideally this should be configurable
(see the comments in the code for more notes).

Fixes FossifyOrg#408.
tom93 added a commit to tom93/Calendar that referenced this issue Jan 18, 2025
The previous implementation was broken in some time zones (see FossifyOrg#408
for details).

The new implementation hard-codes the start of the week to be Monday
to match the previous behaviour. Ideally this should be configurable
(see the comments in the code for more notes).

Fixes FossifyOrg#408.
tom93 added a commit to tom93/Calendar that referenced this issue Jan 18, 2025
The previous implementation was broken in some time zones (see FossifyOrg#408
for details).

The new implementation hard-codes the start of the week to be Monday
to match the previous behaviour. Ideally this should be configurable
(see the comments in the code for more notes).

Fixes FossifyOrg#408.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants