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

[Shawn Landden]

On Mon, Mar 23, 2015 at 12: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.
>
> This is hardly Cockpit specific.
>
>>> 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.
all that would be required would be a hash of the zoneinfo file
>
> 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.
The problem really isn't this bad. With my patch to actually use the
remove timezone setting things are relatively OK. as is documented in
tzset() glibc falls back to UTC.
>
>>> 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
>



-- 
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com