systemd 229: timer unit 'OnCalendar=' calculates wrong execution date

[crashmaster1]

This happens at least using CET time (24 hours) and a timer controlled service which uses 'OnCalendar=' (other time specifications seem to work well).

Example:
Let's say current date and time is:
Sunday, 9:00 CET

Unit file 'test.timer' contains:

[Unit]
...
[Timer]
OnCalendar=Sun 16:00:00
[Install]
WantedBy=multi-user.target

The corresponding 'test.service' should be executed 7 hours later but it don't! 'systemctl list-timers' shows next execution for a week later (Sunday next week and not for today).

This happens with systemd 229-2, downgrading to 228-4 and it works fine again.

[poettering]

probably fall-out from 436dd70. @mustrumr any idea?

[shibumi]

@poettering
Seems like it's not only OnCalendar seems like timers in general are timing wrong..

NEXT                         LEFT    LAST                         PASSED   UNIT           ACTIVATES
Tue 2016-02-23 22:44:58 CET  16s ago Tue 2016-02-23 22:45:14 CET  16ms ago dwupdate.timer dwupdate.service

Or why is NEXT in the past?

Here is my timer:

[Unit]
Description=Run dwupdate.service every 2 seconds

[Timer]
OnActiveSec=0
OnUnitActiveSec=2s
Unit=dwupdate.service

[Install]
WantedBy=default.target

[thurstylark]

I am having the same issue using a timer that triggers a target using OnCalendar=daily
v229-3 on Arch.

Timer:

[Unit]
Description=Reach nightly.target nightly

[Timer]
OnCalendar=daily
Persistent=true
AccuracySec=12h
Unit=nightly.target

[Install]
WantedBy=timers.target

Output of 'systemctl list-timers'

NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
Tue 2016-03-08 00:00:00 CST  2 days ago    Tue 2016-03-08 00:00:00 CST  2 days ago nightly.timer                nightly.target
Fri 2016-03-11 00:00:00 CST  5h 21min left Thu 2016-03-10 00:00:00 CST  18h ago    logrotate.timer              logrotate.service
Fri 2016-03-11 00:00:00 CST  5h 21min left Thu 2016-03-10 00:00:00 CST  18h ago    man-db.timer                 man-db.service
Fri 2016-03-11 00:00:00 CST  5h 21min left Thu 2016-03-10 00:00:00 CST  18h ago    shadow.timer                 shadow.service
Fri 2016-03-11 00:00:00 CST  5h 21min left Thu 2016-03-10 00:00:00 CST  18h ago    updatedb.timer               updatedb.service
Fri 2016-03-11 09:29:07 CST  14h left      Thu 2016-03-10 09:29:07 CST  9h ago     systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
n/a                          n/a           Mon 2016-03-07 09:14:48 CST  3 days ago mdadm-last-resort@md0.timer  mdadm-last-resort@md0.service

7 timers listed.
Pass --all to see loaded but inactive timers, too.

[Yamakaja]

Has anybody found a workaround for this yet?

[hvenev]

Note that asdf.target/service should be stopped in order for asdf.timer to rearm.

[crashmaster1]

@Yamakaia:
The simplest workaround for me was a downgrade to V228, that's what i did and i will wait for V230.
Or compile a later release yourself. Or use another scheduler like cron in the meantime. ;)