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

[Tom Gundersen]

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.

I don't see how this is incorrect now. See below.

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

For the record, I think it IS remoteable now with the recent change.
It all comes down to what you intend the fields to mean. Now we mean
the field to mean "the real localtime of the server (as seen from the
client)", whereas you want it to mean "the localtime the server thinks
it has". If these two notions don't coincide, something is obviously
fucked, but I don't think it is correct to say that the current way of
handling it mean the API is not remotable.

Cheers,

Tom