On 24.03.2015 15:11, Kay Sievers wrote: > On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: >> Exactly because they do not require being upgraded in lock-step, doing >> conversion to the local time locally is "racy". Assuming we have up-to-date >> timezone database locally, with the patch that was merged today we can >> answer the question "what the local time should be remotely", but not >> necessarily "what the local time is remotely". >> >> If we go to the trouble of displaying the remote local time, imho we >> should do it as the remote does. > > No, we should care about the *state* of the system, and that is its > time value and its configured location on earth.
Then stop displaying incorrect "presentation" data in timedatectl. > Systemd has no business in "fixing" the *presentation* logic of these > values. It is not an API for the timezone database. These tools > already exist. > > Please stop trying to add insufficient and half-thought-through APIs > to cover problems which just do not exist in reality or do not need to > be worked-around by systemd. This gives us what we need: $ date '+%s:%:z' So we'll use that instead of timedated. I'll update the wiki page for the timedated DBus interface to note parts of it are just not remotable. Stef _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
