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

[Stef Walter]

On 24.03.2015 15:22, Tom Gundersen wrote:
> 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's better.

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

The latter is the only place where "server local time" is relevant. The
server's UTC time is the one that you can reason about, and display as
"client local time" ... in cases where you want to do that.

But when you're displaying "server local time" it should be according to
the server's zoneinfo.

For example in Cockpit (which again runs in a web browser) when you see:

 Server time: 2015-03-24 21:53
 Time zone: Australia/Tasmania

It means "the current time that the server thinks it is" ... not the
time the browser thinks it is ... not the time the browser thinks the
server should think it is ... But actually the time on the server, as
interpreted by the server.

Yes, I realize this is "presentation" data ...

> If these two notions don't coincide, something is obviously
> fucked,

That's the thing. It's not fucked. There will never be a time when all
zoneinfo's (and copies of moment-timezone.js [0] in our case) laying
around are identical.

But again, If you want to say this is out of scope of systemd, fine.
We'll just use the glibc linked into the remote /usr/bin/date to
interpret the *remote* zoneinfo for us, rather than the glibc linked
into timedated. It's a shame we have to spawn two processes instead of
one ... but so be it.

Stef