[systemd-devel] [systemd-commits] Makefile.am src/shared src/timedate
zbyszek at in.waw.pl
Tue Mar 24 08:07:26 PDT 2015
On Tue, Mar 24, 2015 at 03:32:31PM +0100, Kay Sievers wrote:
> On Tue, Mar 24, 2015 at 3:24 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Tue, Mar 24, 2015 at 07:04:11AM -0700, Kay Sievers 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.
> > That just doesn't make sense. This was *extremely* useful functionality.
> Sure, it was useful, it was still not the right place to solve it.
> With the decision not to support any DST stuff in systemd itself, DST
> parsing did not belong here. Maybe in date(1) or any other tool.
But we cannot pretend timezones don't exists. timedatectl *is* a
high-level tool — the whole point of it's existence was to provide a
nice wrapper around the dbus api to set the timezone. The fact that it
could be used to set timezones and query it in an easy way made it
worthwhile. I don't see anything wrong with the fact that a tool
which allows setting the system timezone also allows displaying some
useful details about the time and timezone. There was nothing wrong
with this functionality in general, only a small issue with conversion
of remote-to-local, which we should work out instead of throwing out
the baby with the bathwater.
> Systemd's job is not to cover exotic features missing in other tools.
> It was removed to stop misguiding people that systemd should to
> provide any of these things on the bus or in its APIs, just because it
> could provide it. In the longer-term this would just end up in a
> half-baked mess, which we need to make sure will not happen.
More information about the systemd-devel