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. > > 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. > >> So obviously we could invent a DBus service called timedated2 (or >> whatever) to do what we need ... but I figured I'd see if timedated >> could do what we needed first. > > I don't think so. Systemd covers operating system data, but I doubt it > should provide "remote glibc" functionality. > >> It seems that timedatectl itself needs information about remote local >> time, since when connecting remotely over DBus it gets the local time >> wrong. [1] > > 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. > > Kay > _______________________________________________ > systemd-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Liberty equality fraternity or death, Shawn Landden ChurchOfGit.com _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
