Proxmox's scheduling syntax does something weird

Astrodata

New Member
Mar 23, 2026
1
0
1
Hi all.
i just upgraded PBS from 3.4 to 4.1 and found something weird using Proxmox's scheduling syntax.
this happend on pbs 3.4 and pbs 4.1, so i think i do misunderstood something
when i test my schedule syntax in shell i get the following:

Code:
root@HostBackup:~# systemd-analyze calendar "Sat *-*-1..31 02:00:00"
  Original form: Sat *-*-1..31 02:00:00
Normalized form: Sat *-*-01..31 02:00:00
    Next elapse: Sat 2026-03-28 02:00:00 CET
       (in UTC): Sat 2026-03-28 01:00:00 UTC
       From now: 4 days left
root@HostBackup:~# systemd-analyze calendar "Sun *-*-1..31 02:00:00"
  Original form: Sun *-*-1..31 02:00:00
Normalized form: Sun *-*-01..31 02:00:00
    Next elapse: Sun 2026-04-05 02:00:00 CEST
       (in UTC): Sun 2026-04-05 00:00:00 UTC
       From now: 1 week 5 days left
root@HostBackup:~# systemd-analyze calendar "Mon *-*-1..31 02:00:00"
  Original form: Mon *-*-1..31 02:00:00
Normalized form: Mon *-*-01..31 02:00:00
    Next elapse: Mon 2026-03-30 02:00:00 CEST
       (in UTC): Mon 2026-03-30 00:00:00 UTC
       From now: 6 days left
root@HostBackup:~#

Output for Sat**** and output for Mon is what i would expecting, but for Sun i would expect the following output:
Code:
root@HostBackup:~# systemd-analyze calendar "Sun *-*-1..31 02:00:00"
  Original form: Sun *-*-1..31 02:00:00
Normalized form: Sun *-*-01..31 02:00:00
    Next elapse: Sun 2026-03-29 02:00:00 CEST
       (in UTC): Sun 2026-03-29 00:00:00 UTC
       From now: 5 days left
root@HostBackup:~#

this seems to happen on normal time, summer time change situation.
is this bug already known?
 
Welcome, @Astrodata
I have the same output in a system which has nothing common to Proxmox:

Code:
@kubuntu:~$ systemd-analyze calendar "Sun *-*-1..31 02:00:00"
  Original form: Sun *-*-1..31 02:00:00
Normalized form: Sun *-*-01..31 02:00:00
    Next elapse: Sun 2026-04-05 02:00:00 CEST
       (in UTC): Sun 2026-04-05 00:00:00 UTC
       From now: 1 week 5 days left

I guess this is the result that on Sunday of time change from "winter" to "summer" time there's no "02:00:00" time.
As I understand the time change, immediately after 01:59:59 there is 03:00:00.

I admit the scheduling consequence is quite surprising for me as well. And contrary to the need.
 
  • Like
Reactions: UdoB
This is another example of systemd "Knows Better" dogma :-(.

Cron is more sensible:

"Daylight Saving Time and other time changes

Local time changes of less than three hours, such as those caused by the start or end of Daylight Saving Time, are handled specially. This only applies to jobs that run at a specific time and jobs that are run with a granularity greater than one hour. Jobs that run more frequently are scheduled normally.

If time has moved forward, those jobs that would have run in the interval that has been skipped will be run immediately. Conversely, if time has moved backward, care is taken to avoid running jobs twice."

( https://linux.die.net/man/8/cron )