Re: systemd-timer way of queuing jobs like 'at' command does ?

[Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>]

On Thu, Dec 22, 2022 at 08:00:06PM +1100, Michael Chapman wrote:
> On Thu, 22 Dec 2022, Andrei Borzenkov wrote:
> > On Thu, Dec 22, 2022 at 11:17 AM Nicolas Pillot
> > <nicolas.pillot@xxxxxxxxx> wrote:
> > >
> > > Hello
> > >
> > > I am wondering if i can dynamically plan jobs (once) using systemd timer. What i mean by that is kind of replicating the usage of the 'at' command
> > >
> > 
> > systemd-run --on-calendar=tomorrow echo I am at replacement
> 
> Curiously that gives me (on v250):
> 
>     $ systemd-run --on-calendar=tomorrow echo I am at replacement
>     Failed to parse calendar event specification: Invalid argument
> 
> Known bug? `systemd-analyze timestamp tomorrow` can parse 
> it...
> 
> This is still slightly different from "at" though, since the timer and 
> service are transient: they are lost if the system is rebooted.

This is because it's a "calendar expression", not a "timestamp":
'systemd-analyze calendar tomorrow' fails. But I'm surprised by this,
and the docs even even say that calendar expressions are a superset of the
timestamp expressions. So it might be a bug. Feel free to file an issue.

Zbyszek