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 > <[email protected]> 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 <[email protected]> > >> 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. Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
