Timers run out of time if mympd starts on a system with wrong time or without RTC (rpi)

[ThecaTTony]

Hello, I have been noticing for some time that the timers stop running at the configured time (or as I explain below, maybe they were running but at different times). The first time I noticed this what I did was to delete them and recreate them, because enabling or disabling them does not change anything.

A few days ago I changed my desk furniture and turned everything off to organize the wires properly, so I also turned off the raspberry pi where mpd and mympd runs. After connecting everything, I turned the rpi back on and went to sleep.
The curious thing is that the timers I have programmed to stop playback, play a stream or stop it later were executed exactly 3:30hs later than they should have and I think this is due to the fact that the initial time of the system was advanced almost that same time interval (3:34:53):

nov 11 20:09:43 pilar systemd-timesyncd[305]: System clock time unset or jumped backwards, restored from recorded timestamp: Sat 2023-11-11 20:09:43 -03
sep 27 23:44:36 pilar systemd-resolved[303]

It could be the case that if mympd starts before the system time is updated (and corrected) it keeps the previous time to run the timers? Or is it a big coincidence?
After noticing that, I restarted the mympd service and the next timer ran at the proper time.

Maybe the ProtectClock=yes option in the systemd service unit has something to do with?

The funny thing is that I used to have an RTC hat, but I removed it to install the DAC hat (Pimoroni Pirate Audio Line-out).

[jcorporation]

The timer start time is calculated as offset to now. It seems it works as designed.