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

[Stef Walter]

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]

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.

It seems that timedatectl itself needs information about remote local
time, since when connecting remotely over DBus it gets the local time
wrong. [1]

Stef

[0] http://stef.thewalter.net/using-dbus-from-javascript-in-cockpit.html

[1]
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029637.html