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

[David Herrmann]

Hi

On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Tue, Mar 24, 2015 at 01:59:40PM +0100, Tom Gundersen wrote:
[...]
>> >>> But it is not systemd's task to cover for missing functionality in the
>> >>> cockpit architecture. We should not add redundant interfaces just
>> >>> provide data for a specific user.
>> >
>> > Even systemd can't reliably consume its own DBus timedated interface
>> > remotely. Even once timedatectl is fixed, the information will be wrong
>> > unless the version of zoneinfo and glibc are identical on both systems
>> > involved.
>>
>> Could you explain this? Is not the ABI stable here? Surely
>> zoneinfo/glibc are backwards compatible and do not require being
>> upgraded in lock-step, so how exactly does this break?
>
> 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".

...and if the remote host-name contains unicode characters our local
host cannot display, should we also transfer the font?

If you local timezone data is out-of-date, it's your problem. Update
it and you get the correct data. Besides, if we assume both DBs are
different, who says that you're interested in the data from the remote
host? If your local host has an old (or newer?) timezone DB, then you
explicitly want to use this. So your view of the timedata should
depend on your local configuration, not on the remote.

Thanks
David