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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 24, 2015 at 01:59:40PM +0100, Tom Gundersen wrote:
> 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?

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.

> >>> 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.
> I can understand the actual data may be out-of-sync, but the formats
> should all be fine, no?
I'd think so.

Zbyszek