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

[Stef Walter]

On 23.03.2015 12:11, Shawn Landden wrote:
> On Sun, Mar 22, 2015 at 10:32 PM, 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().
>>
>> 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...
> The patch is COMPLETELY WRONG, as timezone offsets are differn't for
> differn't times due to DST. Even if this is taken into account there
> are all sorts of races
> with this information around DST switches.

As with the TimeUSec and RTCTimeUSec properties, it's assumed the caller
knows the information is out of date the instant they receive it.

But in that case I guess we shouldn't do
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE...

> How about a
> "LocalTimeUSec" property, for those times that the application doesn't
> have an interest doing timezone calculations and just wants the local
> time on the other machine. 

That's fine with me. Although IMO it's quite unorthodox to have local
time in an integer value counted since the epoch.

<snip>

Stef