[systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

Kay Sievers kay at vrfy.org
Tue Mar 24 07:23:36 PDT 2015

On Tue, Mar 24, 2015 at 3:17 PM, Stef Walter <stefw at redhat.com> wrote:
> On 24.03.2015 15:11, Kay Sievers wrote:
>> On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
>> <zbyszek at 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.

Isn't it fixed with Shawn patch?

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

Which parts are not not-remotable? You get the exact values you need
for a machine, it's current time and location.


More information about the systemd-devel mailing list