[systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset
kay at vrfy.org
Mon Mar 23 08:56:12 PDT 2015
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:
>>> 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
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
> 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. 
Yeah, it's currently a mix of local vs. remote data. If timedatctl
should work correctly on a remote host, it needs to fixed.
More information about the systemd-devel