Bug 1711065

Summary: RFE: add systemd-analyze verb to display timestamps
Product: [Fedora] Fedora Reporter: David Both <dboth>
Component: systemdAssignee: systemd-maint
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: lnykryn, msekleta, s, systemd-maint, zbyszek
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: systemd-243~rc1-1.fc31 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-30 20:35:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Both 2019-05-16 21:04:22 UTC
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.

Comment 1 Zbigniew Jędrzejewski-Szmek 2019-05-16 21:39:01 UTC
--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.

Comment 2 David Both 2019-05-17 01:28:42 UTC
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.

Comment 3 Zbigniew Jędrzejewski-Szmek 2019-05-17 08:06:46 UTC
https://github.com/systemd/systemd/pull/12597

Comment 4 David Both 2019-05-17 12:14:52 UTC
I would be happy to test this fix. 

Thanks!

Comment 5 Zbigniew Jędrzejewski-Szmek 2019-07-30 20:35:31 UTC
Built in rawhide.