On Mon, Mar 23, 2015 at 8:13 PM, Stef Walter <[email protected]> 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 <[email protected]> wrote: >>> On Mon, Mar 23, 2015 at 3:49 PM, Stef Walter <[email protected]> wrote: >>>> On 23.03.2015 15:26, Kay Sievers wrote: >>>>> On Mon, Mar 23, 2015 at 1:46 PM, David Herrmann <[email protected]> >>>>> wrote: >>>>>> Hi >>>>>> >>>>>> On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering >>>>>> <[email protected]> wrote: >>>>>>> On Thu, 19.03.15 14:39, David Herrmann ([email protected]) 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
