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

[Shawn Landden]

On Mon, Mar 23, 2015 at 8:56 AM, Kay Sievers <kay at vrfy.org> wrote:
> 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:
>>>> Hi
>>>>
>>>> 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
>> 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
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com