Systemd Timer Not Catching Up After Sleep

According to the page for systemd timers, specifying Persistent=true should allow a timer to run if an OnCalendar match was made while the device was sleeping. In my experience, this is not working correctly on Bazzite. My timer file looks like:

[Unit]
Description="Enables and disables night mode on boot and at specified times"

[Timer]
# OnBootSec=1min
OnCalendar=*-*-* 09:00:00
OnCalendar=*-*-* 20:00:00
OnCalendar=*-*-* 23:30:00
Persistent=true
Unit=NightMode.service

[Install]
WantedBy=timers.target

I initially had it check on boot but realized that setting Persistent=True is supposed to cover that case as well so I commented that out. Does anyone see any issues with my timer or is the behavior truly bugged in Bazzite? I always have to trigger my script manually after resuming from sleep.

I guess you have checked you timer file by running
systemd-analyze verify blabla.timer

When resuming from sleep you did run
systemctl list-timers --all

?

I’m new to Systemd timers and wasn’t aware of these commands. Running systemctl --user list-timers after a wake up results in:

NEXT                           LEFT LAST                         PASSED UNIT                         ACTIVATES                >
Fri 2026-05-29 20:00:00 PDT 4h 7min Fri 2026-05-29 15:51:41 PDT 46s ago NightMode.timer              NightMode.service

Does this mean that the timer is working correctly because it says PASSED 46 seconds ago? Also running journalctl --user -u NightMode.service results in `May 29 15:51:41 bazzite systemd[2346]: Started NightMode.service - “Enables and disables night mode on boot and at specified times”.`

I guess this would lead to an issue in my script potentially? But simply running the script manually results in the correct behavior so I’m not sure how that could be. My script is:

#!/usr/bin/bash

readonly MORNINGSTART=900
readonly PLAYSTART=2000
readonly NIGHTSTART=2300
current_time="$(date +'%k%M')"

if [ "${current_time}" -ge $MORNINGSTART ] && [ "${current_time}" -lt $NIGHTSTART ]
then
  # It is day time
  if [ "${current_time}" -lt $PLAYSTART ]
  then
    # It is focus time
    qdbus --literal org.kde.KWin /Effects org.kde.kwin.Effects.loadEffect colorblindnesscorrection
    qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/BrightnessControl org.kde.Solid.PowerManagement.Actions.BrightnessControl.setBrightness 10000
  else
    # It is play time
    qdbus --literal org.kde.KWin /Effects org.kde.kwin.Effects.unloadEffect colorblindnesscorrection
    qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/BrightnessControl org.kde.Solid.PowerManagement.Actions.BrightnessControl.setBrightness 10000
  fi
else
  # It is night time
  qdbus --literal org.kde.KWin /Effects org.kde.kwin.Effects.loadEffect colorblindnesscorrection
  qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/BrightnessControl org.kde.Solid.PowerManagement.Actions.BrightnessControl.setBrightness 100
fi

Is there some weird interaction where because it is “catching up” after resuming from sleep, the current time is being read wrong or what am I missing here?

Edit: Also for further confirmation, running the script through the service manually using systemctl --user start NightMode.service also exhibits the correct behavior but not when waking up from sleep… very odd to me. Ex. the brightness of my screen when it went to sleep in night mode was 1% and if the timer is working as intended, the brightness should change to 100% when I just woke the PC up because it was after the morning time.

Am I correct that Bazzite only allows user Systemd timers? Is it a limitation because of it not being a system timer some how and even though I am just resuming from sleep and my user is still logged in, the brightness is unable to be changed from the lock screen or some odd behavior like that maybe?

I don’t use Bazzite but I would be astonished if this were true. There is no reason to allow only user systemd timers.

I think this is a bug in KDE related to modifying these properties while on the lock screen.