[systemd-devel] timezone aware timers

[Lennart Poettering]

On Di, 20.02.18 11:14, Iain Lane (iain at orangesquash.org.uk) wrote:

> Hi systemd friends,
> 
> Sorry if this has been discussed already.
> 
> I'm working on an alarm program. To allow the program to be shut down
> between alarms, they are represented as systemd timers using OnCalendar
> specifications. This mostly works but I think there is one wrinkle
> remaining - they don't handle timezone transitions but always trigger in
> the timezone that was in use when they were started.
> 
> In addition to alarms, you might also want this to schedule housekeeping
> tasks or backups to happen in the night. I think the semantics would be
> something like -
> 
>   * When changing timezones, ensure timers will activate at their
>     configured time in the new local timezone.
>   * Ignore any activation times that are skipped over due to a timezone
>     change.
> 
> I'm not sure, though, what the best way to specify this in a timer unit
> would be. Perhaps either a new timezone specification "local", or a
> boolean flag UpdateWithTimezoneChange. "local" would act like you
> specified the current timezone, but we would go away and recalculate
> the time on a timezone change.

If you don't specify a timezone in timer expression you actually
reference the local time. The only issue is that we don't recognize
timezone changes...

Could you file an RFE issue about this on github?

> I also don't know how we'd get notified of the timezone changing.
> inotify on /etc/timezone?

/etc/timezone is usually a symlink, and iirc we can't install inotify
on a symlink (only in the containing dir, but that means a lot more
wakeups).

The alternative is to watch timedated's bus signals, but quite frankly
I am not too keen on that, since PID 1 depending on service's APIs is
always messy, and means early-boot timezone changes couldn't be
covered (which are not unlikely, since timezone info can be
distributed via dhcp)

So, yeah, maybe a careful /etc inotify watch would be the best option
here after all. Happy to take a PR for that ;-)

(We can probably reuse similar code in journald, to fix #6589)

Lennart

-- 
Lennart Poettering, Red Hat