Reminders → Later: tomorrow and next week keep the hour of the click, not the reminder's #565

New issue

Closed

opened 2026-10-01 10:47:41 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:47:41 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading the Later service against its docstring and its test.

Related to #238.

Checked again on 2026-10-01 against main at 0a5cad587: still present. The code is now at applications/views.py:805-821 (ReminderLaterView.post); later_time and its test are where they were.

later_time() promises to keep "the time of day it was set for … a reminder to ring somebody at ten was set for ten on purpose, and a postponement is a change of day". It returns timezone.now() + n days: the reminder's own time is never read, so the reminder moves to the minute the button was pressed. The addition is also done on a UTC instant, so across a clock change the local hour shifts by one. The test that names the promise asserts exactly what the code does, so it cannot fail on either.

Where: later_time (applications/services.py:554-564); ReminderLaterView.post (applications/views.py:765-781), which calls it without the reminder; test_tomorrow_and_next_week_keep_the_hour_they_were_set_for (tests/test_deadlines.py:397-402), the only test of later_time.
What happens: a reminder "Ring Anna" is due at 10:00. At 16:40 the person presses Put off until tomorrow: it moves to 16:40 tomorrow, not 10:00. In Europe/Paris, pressing Put off until next week at 10:00 on Tuesday 20 October 2026 gives 2026-10-20T08:00Z + 7 days = 2026-10-27T08:00Z, which is 09:00, because summer time ended on the 25th; the success message then says 09:00.
Why it matters: the call gets made at the wrong hour, or the reminder rings in the middle of something else; the docstring and the test name say the opposite of what happens.
Fix: give later_time the reminder. Take the person's local date today plus the days, combine it with timezone.localtime(reminder.due_at).time(), and make the result aware in the current zone (choosing the later instant for a time that does not exist on a change day and the first for one that occurs twice). Keep measuring the day from today, as the comment on LATER_DAYS intends.

Done when

tests/test_deadlines.py has a test that postpones a 10:00 reminder at 16:40 and expects 10:00 the next day, and one that postpones a 10:00 reminder by a week across 25 October 2026 in Europe/Paris and expects 10:00 local; both fail today. The existing test is rewritten, since it restates the implementation.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading the *Later* service against its docstring and its test. Related to #238. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The code is now at `applications/views.py:805-821` (`ReminderLaterView.post`); `later_time` and its test are where they were. `later_time()` promises to keep "the time of day it was set for … a reminder to ring somebody at ten was set for ten on purpose, and a postponement is a change of day". It returns `timezone.now() + n days`: the reminder's own time is never read, so the reminder moves to the minute the button was pressed. The addition is also done on a UTC instant, so across a clock change the local hour shifts by one. The test that names the promise asserts exactly what the code does, so it cannot fail on either. - **Where:** `later_time` (`applications/services.py:554-564`); `ReminderLaterView.post` (`applications/views.py:765-781`), which calls it without the reminder; `test_tomorrow_and_next_week_keep_the_hour_they_were_set_for` (`tests/test_deadlines.py:397-402`), the only test of `later_time`. - **What happens:** a reminder "Ring Anna" is due at 10:00. At 16:40 the person presses *Put off until tomorrow*: it moves to 16:40 tomorrow, not 10:00. In `Europe/Paris`, pressing *Put off until next week* at 10:00 on Tuesday 20 October 2026 gives 2026-10-20T08:00Z + 7 days = 2026-10-27T08:00Z, which is 09:00, because summer time ended on the 25th; the success message then says 09:00. - **Why it matters:** the call gets made at the wrong hour, or the reminder rings in the middle of something else; the docstring and the test name say the opposite of what happens. - **Fix:** give `later_time` the reminder. Take the person's local date today plus the days, combine it with `timezone.localtime(reminder.due_at).time()`, and make the result aware in the current zone (choosing the later instant for a time that does not exist on a change day and the first for one that occurs twice). Keep measuring the day from today, as the comment on `LATER_DAYS` intends. ## Done when - `tests/test_deadlines.py` has a test that postpones a 10:00 reminder at 16:40 and expects 10:00 the next day, and one that postpones a 10:00 reminder by a week across 25 October 2026 in `Europe/Paris` and expects 10:00 local; both fail today. The existing test is rewritten, since it restates the implementation.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:47:41 +00:00

tiagoagueda added the

tier

bug

labels

2026-10-01 10:47:41 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 02:35:50 +00:00

Keep a postponed reminder's hour, in the person's own zone

tiagoagueda closed this issue

2026-10-04 02:35:50 +00:00