Hi On Thu, Mar 19, 2015 at 2:58 PM, Stef Walter <[email protected]> wrote: > On 19.03.2015 14:39, David Herrmann 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? >> >> I'm not really against this bus-call, but I also don't see the point. > > In Cockpit we're running on a different machine, and accessing timedated > remotely. If this information is not available in timedated, we would > need to add another DBus service to expose this information. > > Besides it fits in well with the TimeUSec property.
But TimeUSec is UTC. If you retrieve "TimeUSec" and "Timezone", you can reconstruct the time offset yourself, without any further information, right? >> There's much more information in a timezone file than the offset, so >> why expose the offset but not the other data? > > I would like to be able to do 'timedatectl list-timezones' over DBus as > well. Why? This information should be the same on all machines, right? I don't see why the remote list is of any interest. > Such work would allow timedatectl to work properly with the --host > argument. Currently the output of 'timedatectl status > --host=machine-in-another-timezone.example.com' is full of invalid > information. Yes, but it's the job of timedatectl to print information in the timezone of the remote host, not of the local host. It should retrieve the "Timezone" field and modify it's local timezone if you want the information to be relative to remote timezone, not the local timezone (which I'm not sure you really want). What exactly do you mean with "full of invalid information"? Thanks David _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
