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

[David Herrmann]

Hi

On Thu, Mar 19, 2015 at 2:58 PM, Stef Walter <stefw at redhat.com> 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