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

[Kay Sievers]

On Tue, Mar 24, 2015 at 4:07 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> 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.

Well, we need to limit what we do or we will end up in a total mess.

With your usual rush to apply not thought-through things people ask
for, and your arguments based on the actual status quo instead of a
definition/vision what we want to solve in general and where we want
to go, I needed to make things simpler to stop giving the wrong
impression here.

With the feature removed, it is clear, that systemd has no business in
localtime presentation or DST handling and that is for sure enough
justification to remove it.

Kay