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

Kay Sievers kay at vrfy.org
Mon Mar 23 07:26:44 PDT 2015

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?

Localtime is "presentation only", if the databases are out-of-date,
then they are out-of-date, who cares? We are not in the business to
support unmaintained boxes with a bus api.

It doesn't makes sense to play games here or make wild promises for
stuff that does not even solve a real problem.


More information about the systemd-devel mailing list