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

[Lennart Poettering]

On Thu, 26.03.15 11:57, Kay Sievers (kay at vrfy.org) wrote:

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

That's just a statement of an opinion. I see no explanation for this.

I think I gave a good explanation why I think we should cover all
three kinds of calendar anomalies. Can you explain why the one anomaly
that happens all the time, on pretty much everybody's system you
consider irrelevant?

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

True. And sysvinit worked "fine already today" too.

It's not a question on wether something works fine or not, it's a
question of actually solving real problems.

If you think that DST handling for timer triggers is not a problem, then
you live in a very simple world.

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

Well, it's good that things are so simple for you. But calendar time
handling is really not that simple. You *have* to think of DST. And if
you don't you just avoid dealing with the complexity it brings.

You know, Kay, DST is a real thing. It's an ugly thing, and we all
wish it would not exist. But well, it does, and we better deal with it
and make it managable.

Lennart

-- 
Lennart Poettering, Red Hat