Skip to content

fw/services/notifications: schedule Quiet Time boundaries with cron - #2099

Merged
gmarull merged 2 commits into
coredevices:mainfrom
teslabs:dnd-cron
Sep 18, 2026
Merged

gmarull merged 2 commits into
coredevices:mainfrom
teslabs:dnd-cron

Conversation

@gmarull

@gmarull gmarull commented Sep 17, 2026

Copy link
Copy Markdown
Member

Scheduled Quiet Time was driven by a new_timer armed for "seconds until the next boundary", plus a clock-change hook that rebuilt the timer whenever the wall clock moved. Those are wall-clock events, which is exactly what cron exists for.

This replaces the timer with cron jobs: a start and an end job per enabled schedule (masked to WDAY_WEEKDAYS / WDAY_WEEKENDS) and a midnight job on Monday and Saturday for the weekday ↔ weekend handover. Cron recomputes execute times on clock/DST/timezone changes itself, so do_not_disturb_handle_clock_change() now only re-evaluates whether we are inside a period, which is computed directly from the current time rather than inferred from which boundary the timer had been armed for.

The behaviour is unchanged: test_do_not_disturb now runs against the real cron service and keeps every next-boundary expectation from the old test (17 cases in weekday_weekend_schedule), asserted through a new UNITTEST-only cron_service_get_next_execute_time(). A new case exercises the cron firing path, including the "manual DND is cleared when a scheduled period ends" rule.

Follow-up to the same change in the day/night backlight branch (#2092).

Verified: test_do_not_disturb, test_cron, test_alarm*, test_activity, test_light, test_timeline_peek pass; obelix and asterix firmware build.

🤖 Generated with Claude Code

gmarull and others added 2 commits September 17, 2026 16:09
Lets a test of a cron client assert when its next boundary falls
without reaching into the service's job list.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
The scheduled Quiet Time periods were driven by a new_timer armed for
the number of seconds until the next boundary. That is a wall-clock
event, so any time change (user adjustment, phone sync, DST, time
zone) invalidated the delay, and the service compensated by rebuilding
the timer from the clock change hook. It also encoded the weekday /
weekend handover as a hand-computed "days until the other schedule
starts" delay.

Register cron jobs instead: a start and an end job per enabled
schedule, masked to WDAY_WEEKDAYS / WDAY_WEEKENDS, plus a midnight job
on Monday and Saturday for the handover between the two schedules.
Cron recomputes the jobs itself when the clock changes, so the clock
change hook only re-evaluates whether we are inside a period. Being
inside a period is now computed directly from the current time rather
than inferred from which boundary the timer was armed for.

The unit test runs against the real cron service and keeps the same
next-boundary expectations, now asserted through the service's next
execute time; the private timer-id accessors are gone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
@gmarull
gmarull requested a review from jplexer as a code owner September 17, 2026 14:09
@gmarull
gmarull merged commit 2715ae3 into coredevices:main Sep 18, 2026
48 checks passed
@gmarull
gmarull deleted the dnd-cron branch September 18, 2026 07:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants