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

[Tom Gundersen]

On Mon, Mar 23, 2015 at 8:13 PM, Stef Walter <stefw at redhat.com> wrote:
> Sorry about the encrypted email ... I hit the wrong button.
>
> On 23.03.2015 19:07, Shawn Landden wrote:
>> On Mon, Mar 23, 2015 at 8:56 AM, Kay Sievers <kay at vrfy.org> wrote:
>>> On Mon, Mar 23, 2015 at 3:49 PM, Stef Walter <stefw at redhat.com> wrote:
>>>> On 23.03.2015 15:26, Kay Sievers wrote:
>>>>> On Mon, Mar 23, 2015 at 1:46 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>>>>>> Hi
>>>>>>
>>>>>> On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
>>>>>> <lennart at poettering.net> wrote:
>>>>>>> On Thu, 19.03.15 14:39, David Herrmann (dh.herrmann at gmail.com) wrote:
>>>>>>>
>>>>>>>> Hmm, so this is a convenience call. You could just set tm.tm_zone
>>>>>>>> locally and use mktime() with the value retrieved by "Timezone"? Yeah,
>>>>>>>> the time-api is awful with global variables, but that's not really our
>>>>>>>> fault, is it?
>>>>>>>
>>>>>>> This would not work, as struct tm's .tm_zone field is not sufficient
>>>>>>> to indicate a timezone. The code would have to set $TZ and call tzset().
>>>>>>
>>>>>> I see. The Unix-way of doing things!
>>>>>>
>>>>>>> Given the simplicity of this I'd probably just merge Stef's
>>>>>>> patch... It *is* kinda nice given that the timezone database is
>>>>>>> constantly updated and having this exposed on the bus so that it is
>>>>>>> accessible remotely has the benefit that you get the actual timezone
>>>>>>> information in effect on the remote system, and not a possible
>>>>>>> out-of-date timezone from the local database. If you follow what I mean...
>>>>>>
>>>>>> ..locale data is also updated regularly but we don't export
>>>>>> locale-files on the bus ;)
>>>>>>
>>>>>> Anyway, if we add pseudo-redundant APIs, I'd go with a "LocalTime"
>>>>>> field as Shawn suggested. This is what the bus-user is interested in,
>>>>>> right? If they need more data (like DST), they should just parse
>>>>>> zoneinfo. And with "LocalTime" we avoid any ambiguity regarding DST.
>>>>>
>>>>> Transmitting several absolute time stamps sounds wrong.
>>>>> Transmitting the offset sounds as wrong as tz_minuteswest is and it got killed
>>>>> for that reason.
>>>>>
>>>>> Why does anybody ever need anything else than the actual UTC time and
>>>>> the configured  timezone of the machine?
>>>>
>>>> Yes, we do. In Cockpit we want to show the server's local time, in the
>>>> server's timezone. This is similar to how GNOME shows you the local time
>>>> in the local timezone.
>>>>
>>>> But we don't have easy access to libc and its zoneinfo file parser from
>>>> javascript running in a browser. We do have access to DBus [0]
>>>
>>> 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?

>>> The data systemd provides over the bus is the the same as the running
>>> system provides to the local user: the UTC time + the time zone.
>>> Everything else should be a task of the presentation, in this case
>>> cockpit.
>
> The timezone timedated provides is in presentation format (ie:
> "Australia/Tasmania"), a non-standard identifier, rather than a actual
> information about the timezone. Unless all systems agree on these names
> and have identical versions of the data (ie: zoneinfo), identical
> algorithms for interpreting it (ie: glibc) it is impossible to correctly
> interpret it remotely.

These names are backwards compatible API, right? If zoneinfo changes
the names it uses we are in trouble as we currently symlink
/etc/localtime to whatever the zonefile is. So if these files change
names on upgrades we end up with a dangling symlink.

Also the format of the zoneinfo files, how is that ambiguous?

I can understand the actual data may be out-of-sync, but the formats
should all be fine, no?

> There are several DBus interfaces that possible not remotable, whether
> intentionally or not.
>
> For example NetwortkManager has byte[4] arrays stored in uint32's that
> are completely unusable on a different architecture ... other DBus
> interfaces have local file names as properties ... as so on.
>
> We should mark the timedated interface as non-remotable or call out the
> remotability problems in the documentation.
>
>>> Yeah, it's currently a mix of local vs. remote data. If timedatctl
>>> should work correctly on a remote host, it needs to fixed.
>> I posted a patch for this.
>
> With the current DBus interface, the only way to reliably fix this is to
> exec timedatectl remotely on the other system and pipe the output data.
> See above.
>
> Stef
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel