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

[Kay Sievers]

On Thu, Mar 26, 2015 at 11:48 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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=

These are useful, sure.

>      OnDSTChange=

This is absolutely not needed and we should not get into that business.

> 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.

DST support works all fine already today. I don't see any need for
parsing the tz files here to solve an actual existing problem.

> 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...

No, it shouldn't.

We should stay out of the DST business. Glibc calculates everything
just fine for all needed tasks and we arm the timers accordingly.
There is no need to fiddle with the raw tzfile data here.

Kay