[systemd-devel] [systemd-commits] Makefile.am src/shared src/timedate

[Lennart Poettering]

On Tue, 24.03.15 07:04, Kay Sievers (kay at kemper.freedesktop.org) wrote:

>  Makefile.am                |    2 
>  src/shared/time-dst.c      |  329 ---------------------------------------------
>  src/shared/time-dst.h      |   26 ---
>  src/timedate/timedatectl.c |   56 -------
>  4 files changed, 413 deletions(-)
> 
> New commits:
> commit 16c6ea29348ddac73998f339166f863bee0dfef6
> Author: Kay Sievers <kay at vrfy.org>
> Date:   Tue Mar 24 13:52:04 2015 +0100
> 
>     timedate: remove daylight saving time handling and tzfile parser
>     
>     We planned to support (the conceptually broken) daylight saving
>     time/local time features in the kernel, SCSI, networking, FAT
>     filesystem, but it turned out to be a race we cannot win and do
>     not want to get involved. Systemd should not fiddle with daylight
>     saving time or parse timezone information itself.
>     
>     Leave everything to glibc or tools like date(1) and do not make any
>     promises or raise expectations that systemd should handle anything
>     like this.

For what's it worth, I strongly disagree with the removal of this. 

We do provide OnCalendar= triggers in timer units. They trigger on
calendar time, not on UTC time, and are hence subject to local clock
changes, to local timezone changes, and to the DST changes of the
local timezone. Their time scale is non-linear due to this: it
*mostly* is linear, but under any of these three conditions it will
not be linear anymore, it will jump.

Now, to make calendar time triggers complete I think we must enable
people to at least trigger on threse three kinds of anomalies in the
time scale. As such I think it would make a *ton* of sense to add:

     OnTimeZoneChange=
     OnClockChange=
     OnDSTChange=

settings to .timer units, so that users can explictly watch for any of
them, either separately of the actual calendar expressions, or in
addition to them. 

If we do have all four of OnCalendar=, OnTimeZoneChange=,
OnClockChange= and OnDSTChange= in place, then for the first time we
actually can express timer events in a complete way, and the anomalies
of the wallclock time scale becomes *manageable*, for the first time.

Just removing this code blindly appears misguided to me. It just means
sticking the head in the sand, ignoring completely the fact that we
*do* already provide OnCalendar= timer units, and ignoring that their
time scale is so weirdly non-monotonic. And we leave our users in the
cold, because we provide them with no way to manage the fuckup that
DST is.

I strongly believe that it is our duty to make the non-monotonicity of
the calendar time scale as managable as possible for admins, and that
not only includes triggers on DST changes, but in fact the DST changes
are probably the most important kind of anomaly on the calendar scale,
since even a completely NTP controlled, physically fixed system will
experience them regularly, in contrast to the other kinds of
anomalies.

So yeah, Kay, I think this should be readded and be made useful for
timer units. And if we make use of this for the timer units we might
as well show it in timedatectl...

Lennart

-- 
Lennart Poettering, Red Hat