On Di, 20.02.18 11:14, Iain Lane ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
