Description of problem: systemd-analyze calendar fails on *some* fuzzy timestamps and when using the --iterations= option. Version-Release number of selected component (if applicable): [student@studentvm1 ~]$ systemd-analyze --version systemd 239 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid How reproducible: Every time. Symptoms are consistent in Fedora 29 and 30. Steps to Reproduce: Enter all at the CLI as root or non-root user. 1. [student@studentvm1 ~]$ systemd-analyze calendar 15:21:16 --iterations=4 systemd-analyze: unrecognized option '--iterations=4' or [root@studentvm1 ~]# systemd-analyze calendar --iterations=4 15:21:16 systemd-analyze: unrecognized option '--iterations=4' or [root@studentvm1 ~]# systemd-analyze calendar tomorrow Failed to parse calendar specification 'tomorrow': Invalid argument or [root@studentvm1 ~]# systemd-analyze calendar now Failed to parse calendar specification 'now': Invalid argument But this works: [root@studentvm1 ~]# systemd-analyze calendar saturday Original form: saturday Normalized form: Sat *-*-* 00:00:00 Next elapse: Sat 2019-05-18 00:00:00 EDT (in UTC): Sat 2019-05-18 04:00:00 UTC From now: 1 day 7h left 2. 3. Actual results: Expected results: Additional info: The use of quotes does not alter the symptom. The man pages are not clear as to whether these forms should work with this command, but I would certainly expect them to.
--iterations= was added in systemd-242. It's does not exist in v239 which is in F29. 'systemd-analyze calendar' parses calendar entries, not timestamps. And e.g. "tomorrow" and "now" are timestamps, and describe only a single specific point in time. The confusion probably is caused by the fact that certain entries are both valid calendar entries and timestamps. But the meaning is different: "11:12:13" parsed a calendar entry means "11:12:13" on any day, i.e. *-*-* 11:12:13 in normalized form, but "11:12:13" parsed as a timestamp means just one specific time, e.g. "Fri 2019-05-17 09:12:13 UTC" as I'm typing this. We should probably add an equivalent tool to parse and display timestamps. I'll retitle the bug accordingly.
Thanks for your quick response. Perhaps a bit of clarification in the systemd.time(7) man page would help alleviate the confusion until a new tool can be created. Or just add the unction to systemd-analyze calendar.
https://github.com/systemd/systemd/pull/12597
I would be happy to test this fix. Thanks!
Built in rawhide.