Is your feature request related to a problem? Please describe.

systemd sticks to a datetime format that "deliberately" differs from ISO 8601 (and RFC 3339), as defined in https://github.com/systemd/systemd/blob/master/man/systemd.time.xml. Although having a nicely human readable date format is appreciated, breaking standards is not. This bugs me a bit when working with systemd.

Follow up to #5194.

Describe the solution you'd like

It is possible to have human readable and comply to existing standards if we want to.

I am not sure it's [ISO 8601] that sensible. We deliberately opted for a different native format we output and parse, since the "T" and "Z" stuff is hardly friendly for humans to read...

@poettering RFC 3339 comes to the rescue:

NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively.
NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.

So 2019-12-22 12:13:23+01:00 or 2019-12-22 11:13:23z is both valid according to RFC 3339. And I don’t think that is worse than the 2019-12-22 12:13:23 CET.

The weekday at the beginning is useful and (with much good will) could be seen as outside of the RFC 3339 date string.

For testing, I wrote wrappers for systemctl status and journalctl which changes the date format to RFC 3339, ref: https://github.com/ypid/scripts/blob/master/sc, https://github.com/ypid/scripts/blob/master/rl

Describe alternatives you've considered

Open for discussion.