Unless you want to run something every thirty seconds.
Or have it run, if the computer wasn't turned on when the task should have run.
You can run the command with time, get the real field, subtract from 30, sleep that amount and run the command again in a script, and call that every minute from cron.
If the command is really instant you can do "command & sleep 30; command".
heh.
Or just have two cron jobs:
* * * * * user dothing
* * * * * user sleep 30 && dothing
them you don't need to muck about noting start time if `dothing` could take a significantly variable number of seconds to complete. Many moons ago I did something similar for a task that I wanted running every 10 seconds (it was a quick hack taking a few readings and dumping the data for me to later graph).If the task might sometimes take 30 seconds to run you have extra faf debouncing it to avoid race conditions, with this solution or yours, which IIRC systemd timers will deal with (by being configurable to not run the next instance if the previous has not yet completed).
workarounds are ugly. why not just have the ability to begin with?
A very nice UX, indeed. Ah but it's composable!