Discussion:
[PATCH] timedated: Add a LocalOffset property for timezone offset
(too old to reply)
Stef Walter
2015-03-19 10:24:50 UTC
Permalink
This property is in usec (like the TimeUSec property) and allows
retrieving the timezone offset for the machine. This is particularly
usable for remote callers.
---
src/timedate/timedated.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..e384b36 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -361,6 +361,22 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}

+static int property_get_local_offset(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm *tm;
+ time_t dummy = 0;
+
+ assert_se(tm = localtime(&dummy));
+ return sd_bus_message_append(reply, "t", (uint64_t)(tm->tm_gmtoff * 1000000));
+}
+
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -440,7 +456,8 @@ static int method_set_timezone(sd_bus *bus, sd_bus_message *m, void *userdata, s
LOG_MESSAGE("Changed time zone to '%s'.", c->zone),
NULL);

- sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1", "Timezone", NULL);
+ sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1",
+ "Timezone", "LocalOffset", NULL);

return sd_bus_reply_method_return(m, NULL);
}
@@ -666,6 +683,7 @@ static int method_set_ntp(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bus
static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_VTABLE_START(0),
SD_BUS_PROPERTY("Timezone", "s", NULL, offsetof(Context, zone), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+ SD_BUS_PROPERTY("LocalOffset", "t", property_get_local_offset, 0, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("LocalRTC", "b", bus_property_get_bool, offsetof(Context, local_rtc), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("CanNTP", "b", bus_property_get_bool, offsetof(Context, can_ntp), 0),
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
--
2.3.3
David Herrmann
2015-03-19 13:39:57 UTC
Permalink
Hi
Post by Stef Walter
This property is in usec (like the TimeUSec property) and allows
retrieving the timezone offset for the machine. This is particularly
usable for remote callers.
---
src/timedate/timedated.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..e384b36 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -361,6 +361,22 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}
+static int property_get_local_offset(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm *tm;
+ time_t dummy = 0;
+
+ assert_se(tm = localtime(&dummy));
+ return sd_bus_message_append(reply, "t", (uint64_t)(tm->tm_gmtoff * 1000000));
+}
+
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?

I'm not really against this bus-call, but I also don't see the point.
There's much more information in a timezone file than the offset, so
why expose the offset but not the other data?

Thanks
David
Post by Stef Walter
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -440,7 +456,8 @@ static int method_set_timezone(sd_bus *bus, sd_bus_message *m, void *userdata, s
LOG_MESSAGE("Changed time zone to '%s'.", c->zone),
NULL);
- sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1", "Timezone", NULL);
+ sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1",
+ "Timezone", "LocalOffset", NULL);
return sd_bus_reply_method_return(m, NULL);
}
@@ -666,6 +683,7 @@ static int method_set_ntp(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bus
static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_VTABLE_START(0),
SD_BUS_PROPERTY("Timezone", "s", NULL, offsetof(Context, zone), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+ SD_BUS_PROPERTY("LocalOffset", "t", property_get_local_offset, 0, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("LocalRTC", "b", bus_property_get_bool, offsetof(Context, local_rtc), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("CanNTP", "b", bus_property_get_bool, offsetof(Context, can_ntp), 0),
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
--
2.3.3
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Stef Walter
2015-03-19 13:58:14 UTC
Permalink
Post by David Herrmann
Hi
Post by Stef Walter
This property is in usec (like the TimeUSec property) and allows
retrieving the timezone offset for the machine. This is particularly
usable for remote callers.
---
src/timedate/timedated.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..e384b36 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -361,6 +361,22 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}
+static int property_get_local_offset(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm *tm;
+ time_t dummy = 0;
+
+ assert_se(tm = localtime(&dummy));
+ return sd_bus_message_append(reply, "t", (uint64_t)(tm->tm_gmtoff * 1000000));
+}
+
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?
I'm not really against this bus-call, but I also don't see the point.
In Cockpit we're running on a different machine, and accessing timedated
remotely. If this information is not available in timedated, we would
need to add another DBus service to expose this information.

Besides it fits in well with the TimeUSec property.
Post by David Herrmann
There's much more information in a timezone file than the offset, so
why expose the offset but not the other data?
I would like to be able to do 'timedatectl list-timezones' over DBus as
well.

Such work would allow timedatectl to work properly with the --host
argument. Currently the output of 'timedatectl status
--host=machine-in-another-timezone.example.com' is full of invalid
information.

Stef
David Herrmann
2015-03-19 14:17:31 UTC
Permalink
Hi
Post by Stef Walter
Post by David Herrmann
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?
I'm not really against this bus-call, but I also don't see the point.
In Cockpit we're running on a different machine, and accessing timedated
remotely. If this information is not available in timedated, we would
need to add another DBus service to expose this information.
Besides it fits in well with the TimeUSec property.
But TimeUSec is UTC. If you retrieve "TimeUSec" and "Timezone", you
can reconstruct the time offset yourself, without any further
information, right?
Post by Stef Walter
Post by David Herrmann
There's much more information in a timezone file than the offset, so
why expose the offset but not the other data?
I would like to be able to do 'timedatectl list-timezones' over DBus as
well.
Why? This information should be the same on all machines, right? I
don't see why the remote list is of any interest.
Post by Stef Walter
Such work would allow timedatectl to work properly with the --host
argument. Currently the output of 'timedatectl status
--host=machine-in-another-timezone.example.com' is full of invalid
information.
Yes, but it's the job of timedatectl to print information in the
timezone of the remote host, not of the local host. It should retrieve
the "Timezone" field and modify it's local timezone if you want the
information to be relative to remote timezone, not the local timezone
(which I'm not sure you really want).

What exactly do you mean with "full of invalid information"?

Thanks
David
Stef Walter
2015-03-19 14:35:18 UTC
Permalink
Post by David Herrmann
Hi
Post by Stef Walter
Post by David Herrmann
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?
I'm not really against this bus-call, but I also don't see the point.
In Cockpit we're running on a different machine, and accessing timedated
remotely. If this information is not available in timedated, we would
need to add another DBus service to expose this information.
Besides it fits in well with the TimeUSec property.
But TimeUSec is UTC. If you retrieve "TimeUSec" and "Timezone", you
can reconstruct the time offset yourself, without any further
information, right?
No, the Timezone field is textual and unusable in a browser (unless you
reimplement all of /usr/share/zoneinfo in the browser).
Post by David Herrmann
Post by Stef Walter
Post by David Herrmann
There's much more information in a timezone file than the offset, so
why expose the offset but not the other data?
I would like to be able to do 'timedatectl list-timezones' over DBus as
well.
Why? This information should be the same on all machines, right? I
don't see why the remote list is of any interest.
Because Cockpit is running in a browser, and accesses DBus from a
browser. But I guess we could implement our own DBus timedated2
interface which exposes the zoneinfo information. I just figured
timedated would be a natural place for such an API.
Post by David Herrmann
Post by Stef Walter
Such work would allow timedatectl to work properly with the --host
argument. Currently the output of 'timedatectl status
--host=machine-in-another-timezone.example.com' is full of invalid
information.
Yes, but it's the job of timedatectl to print information in the
timezone of the remote host, not of the local host. It should retrieve
the "Timezone" field and modify it's local timezone if you want the
information to be relative to remote timezone, not the local timezone
(which I'm not sure you really want).
What exactly do you mean with "full of invalid information"?
Example below. First set of timedatectl output is correct (since I SSH
and then invoke timedatectl) ... second set has lots of incorrect
fields, since timedatectl accesses timedated remotely:

$ ssh 192.168.11.155 timedatectl
Local time: Fr 2015-03-20 01:31:41 AEDT
Universal time: Do 2015-03-19 14:31:41 UTC
RTC time: Do 2015-03-19 14:31:41
Time zone: Australia/Tasmania (AEDT, +1100)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
So 2014-10-05 01:59:59 AEST
So 2014-10-05 03:00:00 AEDT
Next DST change: DST ends (the clock jumps one hour backwards) at
So 2015-04-05 02:59:59 AEDT
So 2015-04-05 02:00:00 AEST

$ timedatectl --host=192.168.11.155
Local time: Do 2015-03-19 15:31:50 CET
Universal time: Do 2015-03-19 14:31:50 UTC
RTC time: Do 2015-03-19 14:31:50
Time zone: Australia/Tasmania (CET, +0100)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: no
Last DST change: DST ended at
So 2014-10-26 02:59:59 CEST
So 2014-10-26 02:00:00 CET
Next DST change: DST begins (the clock jumps one hour forward) at
So 2015-03-29 01:59:59 CET
So 2015-03-29 03:00:00 CEST



In particular the following fields are incorrect in the second set of
output:

Local time: Do 2015-03-19 15:31:50 CET
Time zone: Australia/Tasmania (CET, +0100)
Last DST change: DST ended at
So 2014-10-26 02:59:59 CEST
So 2014-10-26 02:00:00 CET
Next DST change: DST begins (the clock jumps one hour forward) at
So 2015-03-29 01:59:59 CET
So 2015-03-29 03:00:00 CEST


Cheers,

Stef
Shawn Landden
2015-03-23 11:39:38 UTC
Permalink
Also allow getting time from time(2) when BUS_TRANSPORT_MACHINE.
---
src/timedate/timedatectl.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9e04f8f..7c9bd11 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -106,14 +106,17 @@ static void print_status_info(const StatusInfo *i) {

/* Enforce the values of /etc/localtime */
if (getenv("TZ")) {
- fprintf(stderr, "Warning: Ignoring the TZ variable. Reading the system's time zone setting only.\n\n");
+ fprintf(stderr, "Warning: Ignoring the TZ variable.\n\n");
unsetenv("TZ");
}

+ setenv("TZ", i->timezone, false);
+ tzset();
+
if (i->time != 0) {
sec = (time_t) (i->time / USEC_PER_SEC);
have_time = true;
- } else if (arg_transport == BUS_TRANSPORT_LOCAL) {
+ } else if (IN_SET(arg_transport, BUS_TRANSPORT_REMOTE, BUS_TRANSPORT_MACHINE)) {
sec = time(NULL);
have_time = true;
} else
--
2.2.1.209.g41e5f3a
Lennart Poettering
2015-03-23 05:32:46 UTC
Permalink
Post by David Herrmann
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...
Post by David Herrmann
I'm not really against this bus-call, but I also don't see the point.
There's much more information in a timezone file than the offset, so
why expose the offset but not the other data?
Thanks
David
Post by Stef Walter
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -440,7 +456,8 @@ static int method_set_timezone(sd_bus *bus, sd_bus_message *m, void *userdata, s
LOG_MESSAGE("Changed time zone to '%s'.", c->zone),
NULL);
- sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1", "Timezone", NULL);
+ sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1",
+ "Timezone", "LocalOffset", NULL);
return sd_bus_reply_method_return(m, NULL);
}
@@ -666,6 +683,7 @@ static int method_set_ntp(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bus
static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_VTABLE_START(0),
SD_BUS_PROPERTY("Timezone", "s", NULL, offsetof(Context, zone), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+ SD_BUS_PROPERTY("LocalOffset", "t", property_get_local_offset, 0, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("LocalRTC", "b", bus_property_get_bool, offsetof(Context, local_rtc), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("CanNTP", "b", bus_property_get_bool, offsetof(Context, can_ntp), 0),
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
--
2.3.3
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
Shawn Landden
2015-03-23 11:11:18 UTC
Permalink
On Sun, Mar 22, 2015 at 10:32 PM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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.

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. In any other case I think the client has to
do proper timezone calculations.

I could write a patch for a "TZDataVersion" field that holds the tzdata release.
Post by Lennart Poettering
Post by David Herrmann
I'm not really against this bus-call, but I also don't see the point.
There's much more information in a timezone file than the offset, so
why expose the offset but not the other data?
Thanks
David
Post by Stef Walter
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -440,7 +456,8 @@ static int method_set_timezone(sd_bus *bus, sd_bus_message *m, void *userdata, s
LOG_MESSAGE("Changed time zone to '%s'.", c->zone),
NULL);
- sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1", "Timezone", NULL);
+ sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", "org.freedesktop.timedate1",
+ "Timezone", "LocalOffset", NULL);
return sd_bus_reply_method_return(m, NULL);
}
@@ -666,6 +683,7 @@ static int method_set_ntp(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bus
static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_VTABLE_START(0),
SD_BUS_PROPERTY("Timezone", "s", NULL, offsetof(Context, zone), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+ SD_BUS_PROPERTY("LocalOffset", "t", property_get_local_offset, 0, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("LocalRTC", "b", bus_property_get_bool, offsetof(Context, local_rtc), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("CanNTP", "b", bus_property_get_bool, offsetof(Context, can_ntp), 0),
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
--
2.3.3
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com
Shawn Landden
2015-03-23 11:24:38 UTC
Permalink
---
src/timedate/timedated.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..f83b99c 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -38,6 +38,7 @@
#include "bus-common-errors.h"
#include "event-util.h"
#include "selinux-util.h"
+#include "time-util.h"

#define NULL_ADJTIME_UTC "0.0 0 0\n0\nUTC\n"
#define NULL_ADJTIME_LOCAL "0.0 0 0\n0\nLOCAL\n"
@@ -361,6 +362,28 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}

+/* gmtime(LocalTimeUSec % USEC_PER_SEC) is useful as long as you ignore GNU
+ * extensions of tm_gmtoff and tm_zone, and their ourgrowth in strftime(3)
+ */
+static int property_get_local_time(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm tm;
+ struct timespec ts;
+ usec_t t;
+
+ t = now(CLOCK_REALTIME);
+ (void)timespec_store(&ts, t);
+ assert_se(localtime_r(&dummy, &ts.tv_sec));
+ return sd_bus_message_append(reply, "t", t + (tm->tm_gmtoff * USEC_PER_SEC));
+}
+
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -671,6 +694,7 @@ static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("NTPSynchronized", "b", property_get_ntp_sync, 0, 0),
SD_BUS_PROPERTY("TimeUSec", "t", property_get_time, 0, 0),
+ SD_BUS_PROPERTY("LocalTimeUSec", "t", property_get_local_time, 0, 0),
SD_BUS_PROPERTY("RTCTimeUSec", "t", property_get_rtc_time, 0, 0),
SD_BUS_METHOD("SetTime", "xbb", NULL, method_set_time, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("SetTimezone", "sb", NULL, method_set_timezone, SD_BUS_VTABLE_UNPRIVILEGED),
--
2.2.1.209.g41e5f3a
Zbigniew Jędrzejewski-Szmek
2015-03-24 01:52:36 UTC
Permalink
Post by Shawn Landden
---
src/timedate/timedated.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..f83b99c 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -38,6 +38,7 @@
#include "bus-common-errors.h"
#include "event-util.h"
#include "selinux-util.h"
+#include "time-util.h"
#define NULL_ADJTIME_UTC "0.0 0 0\n0\nUTC\n"
#define NULL_ADJTIME_LOCAL "0.0 0 0\n0\nLOCAL\n"
@@ -361,6 +362,28 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}
+/* gmtime(LocalTimeUSec % USEC_PER_SEC) is useful as long as you ignore GNU
+ * extensions of tm_gmtoff and tm_zone, and their ourgrowth in strftime(3)
+ */
+static int property_get_local_time(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm tm;
+ struct timespec ts;
+ usec_t t;
+
+ t = now(CLOCK_REALTIME);
+ (void)timespec_store(&ts, t);
+ assert_se(localtime_r(&dummy, &ts.tv_sec));
+ return sd_bus_message_append(reply, "t", t + (tm->tm_gmtoff * USEC_PER_SEC));
+}
+
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -671,6 +694,7 @@ static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("NTPSynchronized", "b", property_get_ntp_sync, 0, 0),
SD_BUS_PROPERTY("TimeUSec", "t", property_get_time, 0, 0),
+ SD_BUS_PROPERTY("LocalTimeUSec", "t", property_get_local_time, 0, 0),
SD_BUS_PROPERTY("RTCTimeUSec", "t", property_get_rtc_time, 0, 0),
SD_BUS_METHOD("SetTime", "xbb", NULL, method_set_time, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("SetTimezone", "sb", NULL, method_set_timezone, SD_BUS_VTABLE_UNPRIVILEGED)
This patch seems the most reasonable of the proposed solutions.
It answers the question "What does the remote host think local time is?"
unambigously.

The other patch proposed by Shawn mixes the remote UTC time with local
information about timezones, which doesn't seem as clean.
Post by Shawn Landden
Transmitting several absolute time stamps sounds wrong.
The second timestamp is what the user sees, so in some way it is a
very significant thing. It is the outcome of the remote knowledge
about the time and its config and timezone database. We aren't making
any promises about the accuracy of that, but just trying to accurately
convey that information. Seems fine to me to transmit this bit of
information.

Zbyszek
Shawn Landden
2015-03-24 04:34:48 UTC
Permalink
On Mon, Mar 23, 2015 at 6:52 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Post by Shawn Landden
---
src/timedate/timedated.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..f83b99c 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -38,6 +38,7 @@
#include "bus-common-errors.h"
#include "event-util.h"
#include "selinux-util.h"
+#include "time-util.h"
#define NULL_ADJTIME_UTC "0.0 0 0\n0\nUTC\n"
#define NULL_ADJTIME_LOCAL "0.0 0 0\n0\nLOCAL\n"
@@ -361,6 +362,28 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}
+/* gmtime(LocalTimeUSec % USEC_PER_SEC) is useful as long as you ignore GNU
+ * extensions of tm_gmtoff and tm_zone, and their ourgrowth in strftime(3)
+ */
+static int property_get_local_time(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm tm;
+ struct timespec ts;
+ usec_t t;
+
+ t = now(CLOCK_REALTIME);
+ (void)timespec_store(&ts, t);
+ assert_se(localtime_r(&dummy, &ts.tv_sec));
+ return sd_bus_message_append(reply, "t", t + (tm->tm_gmtoff * USEC_PER_SEC));
+}
+
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -671,6 +694,7 @@ static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("NTPSynchronized", "b", property_get_ntp_sync, 0, 0),
SD_BUS_PROPERTY("TimeUSec", "t", property_get_time, 0, 0),
+ SD_BUS_PROPERTY("LocalTimeUSec", "t", property_get_local_time, 0, 0),
SD_BUS_PROPERTY("RTCTimeUSec", "t", property_get_rtc_time, 0, 0),
SD_BUS_METHOD("SetTime", "xbb", NULL, method_set_time, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("SetTimezone", "sb", NULL, method_set_timezone, SD_BUS_VTABLE_UNPRIVILEGED)
This patch seems the most reasonable of the proposed solutions.
It answers the question "What does the remote host think local time is?"
unambigously.
The other patch proposed by Shawn mixes the remote UTC time with local
information about timezones, which doesn't seem as clean.
These are not for the same problem. We need both. I want to ship a
checksum of the zoneinfo file with the timezone, but its hard to do
this cleanly as using coreutils from C is a PITA.
Post by Zbigniew Jędrzejewski-Szmek
Post by Shawn Landden
Transmitting several absolute time stamps sounds wrong.
The second timestamp is what the user sees, so in some way it is a
very significant thing. It is the outcome of the remote knowledge
about the time and its config and timezone database. We aren't making
any promises about the accuracy of that, but just trying to accurately
convey that information. Seems fine to me to transmit this bit of
information.
Zbyszek
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Shawn Landden
Kay Sievers
2015-03-24 11:17:20 UTC
Permalink
Post by Shawn Landden
On Mon, Mar 23, 2015 at 6:52 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Post by Shawn Landden
---
src/timedate/timedated.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..f83b99c 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -38,6 +38,7 @@
#include "bus-common-errors.h"
#include "event-util.h"
#include "selinux-util.h"
+#include "time-util.h"
#define NULL_ADJTIME_UTC "0.0 0 0\n0\nUTC\n"
#define NULL_ADJTIME_LOCAL "0.0 0 0\n0\nLOCAL\n"
@@ -361,6 +362,28 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}
+/* gmtime(LocalTimeUSec % USEC_PER_SEC) is useful as long as you ignore GNU
+ * extensions of tm_gmtoff and tm_zone, and their ourgrowth in strftime(3)
+ */
+static int property_get_local_time(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm tm;
+ struct timespec ts;
+ usec_t t;
+
+ t = now(CLOCK_REALTIME);
+ (void)timespec_store(&ts, t);
+ assert_se(localtime_r(&dummy, &ts.tv_sec));
+ return sd_bus_message_append(reply, "t", t + (tm->tm_gmtoff * USEC_PER_SEC));
+}
+
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -671,6 +694,7 @@ static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("NTPSynchronized", "b", property_get_ntp_sync, 0, 0),
SD_BUS_PROPERTY("TimeUSec", "t", property_get_time, 0, 0),
+ SD_BUS_PROPERTY("LocalTimeUSec", "t", property_get_local_time, 0, 0),
SD_BUS_PROPERTY("RTCTimeUSec", "t", property_get_rtc_time, 0, 0),
SD_BUS_METHOD("SetTime", "xbb", NULL, method_set_time, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("SetTimezone", "sb", NULL, method_set_timezone, SD_BUS_VTABLE_UNPRIVILEGED)
This patch seems the most reasonable of the proposed solutions.
It answers the question "What does the remote host think local time is?"
unambigously.
The other patch proposed by Shawn mixes the remote UTC time with local
information about timezones, which doesn't seem as clean.
These are not for the same problem. We need both. I want to ship a
checksum of the zoneinfo file with the timezone, but its hard to do
this cleanly as using coreutils from C is a PITA.
Again, systemd is NOT a "remote glibc" API. We are not doing that.

Kay
Kay Sievers
2015-03-24 11:16:26 UTC
Permalink
On Tue, Mar 24, 2015 at 2:52 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Post by Shawn Landden
---
src/timedate/timedated.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..f83b99c 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -38,6 +38,7 @@
#include "bus-common-errors.h"
#include "event-util.h"
#include "selinux-util.h"
+#include "time-util.h"
#define NULL_ADJTIME_UTC "0.0 0 0\n0\nUTC\n"
#define NULL_ADJTIME_LOCAL "0.0 0 0\n0\nLOCAL\n"
@@ -361,6 +362,28 @@ static int property_get_time(
return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
}
+/* gmtime(LocalTimeUSec % USEC_PER_SEC) is useful as long as you ignore GNU
+ * extensions of tm_gmtoff and tm_zone, and their ourgrowth in strftime(3)
+ */
+static int property_get_local_time(
+ sd_bus *bus,
+ const char *path,
+ const char *interface,
+ const char *property,
+ sd_bus_message *reply,
+ void *userdata,
+ sd_bus_error *error)
+{
+ struct tm tm;
+ struct timespec ts;
+ usec_t t;
+
+ t = now(CLOCK_REALTIME);
+ (void)timespec_store(&ts, t);
+ assert_se(localtime_r(&dummy, &ts.tv_sec));
+ return sd_bus_message_append(reply, "t", t + (tm->tm_gmtoff * USEC_PER_SEC));
+}
+
static int property_get_ntp_sync(
sd_bus *bus,
const char *path,
@@ -671,6 +694,7 @@ static const sd_bus_vtable timedate_vtable[] = {
SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("NTPSynchronized", "b", property_get_ntp_sync, 0, 0),
SD_BUS_PROPERTY("TimeUSec", "t", property_get_time, 0, 0),
+ SD_BUS_PROPERTY("LocalTimeUSec", "t", property_get_local_time, 0, 0),
SD_BUS_PROPERTY("RTCTimeUSec", "t", property_get_rtc_time, 0, 0),
SD_BUS_METHOD("SetTime", "xbb", NULL, method_set_time, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("SetTimezone", "sb", NULL, method_set_timezone, SD_BUS_VTABLE_UNPRIVILEGED)
This patch seems the most reasonable of the proposed solutions.
It answers the question "What does the remote host think local time is?"
unambigously.
The other patch proposed by Shawn mixes the remote UTC time with local
information about timezones, which doesn't seem as clean.
Post by Shawn Landden
Transmitting several absolute time stamps sounds wrong.
The second timestamp is what the user sees, so in some way it is a
very significant thing. It is the outcome of the remote knowledge
about the time and its config and timezone database. We aren't making
any promises about the accuracy of that, but just trying to accurately
convey that information. Seems fine to me to transmit this bit of
information.
No, it is not fine, and we are not going to do that.

We do not transmit several timestamps, the local time on the remote
machine is UTC + its configured location. Tools who represent that
need to convert it into their presentation and not systemd.

Kay
Stef Walter
2015-03-23 11:42:53 UTC
Permalink
Post by Shawn Landden
On Sun, Mar 22, 2015 at 10:32 PM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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...
Post by Shawn Landden
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
Shawn Landden
2015-03-23 11:47:02 UTC
Permalink
Post by Stef Walter
Post by Shawn Landden
On Sun, Mar 22, 2015 at 10:32 PM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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.
Your patch is a whole hour slow during daylight savings time. (The
epoch, when you query the offset for, is standard time as it is during
January.)
Post by Stef Walter
But in that case I guess we shouldn't do
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE...
Fixed.
Post by Stef Walter
Post by Shawn Landden
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
--
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com
David Herrmann
2015-03-23 12:46:15 UTC
Permalink
Hi

On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.

Thanks
David
Kay Sievers
2015-03-23 14:26:44 UTC
Permalink
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.

Kay
Stef Walter
2015-03-23 14:49:23 UTC
Permalink
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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
Kay Sievers
2015-03-23 15:56:12 UTC
Permalink
Post by Stef Walter
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.
Post by Stef Walter
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.
Post by Stef Walter
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.

Kay
Kay Sievers
2015-03-23 17:07:27 UTC
Permalink
Post by Kay Sievers
Post by Stef Walter
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.
Btw, we had plans to support the kernel' side of localtime (really
broken by design) for FAT and SCSI and network stuff, but it turned
out to be an unsupportable mess, and we just declared FAT timestamps
as UTC (like Android does).

Unless someone has an idea how to fix and use all that reliably, I'll
just go and remove the DST timezone data parser src/shared/time-dst.c
and its user in timedatctl.

Thanks,
Kay
Shawn Landden
2015-03-23 18:07:43 UTC
Permalink
Post by Kay Sievers
Post by Stef Walter
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.
Post by Stef Walter
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.
Post by Stef Walter
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.
Post by Kay Sievers
Kay
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com
Stef Walter
2015-03-23 18:42:02 UTC
Permalink
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
David Herrmann
2015-03-23 19:09:11 UTC
Permalink
Hi
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2
hQIOA/Dzx7eUN7W0EAgAgOsjwL/aEhn5prcOPnPCWCVcmINma17E5K4ysdpJP3vB
wuIF/L/0b1uhoDUgF1oiK9YwEpJyY1BSFt4HmaVnLw38cNL04u/WY+PUFsT0G0rV
3fu7dl1Mxnjab63ncg4aPVrhYVqGbaCohbAjbmmgGX9Ty/Ey3shItWW6oGm3qbwJ
IeXEP/2VUcoL7SvW66qPE+gl+HWPkK9qEQXWXowg+gHEnyam3uo9DQpOUf+Yk5QA
aFTqxjJB/BU96eVKJAAOU92603BCcDrOzPW13EF670K3Ce5p9GTJomTsklyp3pqF
8dq7ekqASUQPDEkpdIe6LX4XiPzYaBu6Gripej2NvQf/U1iyqOyFdm60M/o2F51j
+hLRO8Te2Oz6V79Mvxoes6twR1LeT4sBPR7ljncMgjf8Ps76uDzedt1kw8uCR9eU
IpESSi8PFke5GOGDs3LItMr4oIA2alLQmo9dgsvRUOoSCmQw/tcnjH+sSC0PLZie
g09xk6pb/YgyRuOWJUXlroWWzEio89QkMpi4Nqmsji9F/omMaiUxjXL1RzdoAZH8
ePxQj8is7Vp6wheB0PXrtEmTKufQgw9syNYRyDDzVzNTOy2L8fkfBpJJgfX1A9WX
Pou0C9Ju/k1sKfbFhZBMSlqplfiOzkSsKmbQSyU40ws82PoDf/murnzsLgOe7q58
4dLrARBNfQp6oMYt+UMiotWlSsrv2mIDtcUbpAsbePxDoy+GcD9pJSMMNgG8bTUE
RPd7VevuR2mP7H94Qofu7SSGtrfVKuDFazQ9lDbF0ovCbmTmEnT48QbJvvtWz8yB
6qQq+6MNQeRETlVeu2pSPzleAqBKT0EltC9Ux4TO3qBJi56+mMCr4zVR4Icd1QAn
DyKaQyMykkk2LV7ty4Wx1f+Fo8JVjI/UYBhm6e23BlOwiftregYd+oVYksi9MmzA
w9ybMP/nmxFlHWrm2YdjvLkThJRyPos+LRMTlPtvi9aj4W7tzqWl4RzUirv8ppva
yCBIUMjyiBThdSZLFnpzI05OzjPme8SwmEoHpn15UlluFkyaP6mFLeOlaIV098zK
vMMct86XBEYSyObkeeVJXdbpF3bTSo4bUR0AVyt6q58QhgGnRAMFhly87Ctck0Bg
1oMyu8CvAim2qI+OOU7FmPi1a+8MVVESYHJP6XC6k/uIAYp3A6AALiNkVW8kIvjC
FdOJoVwGWdvtDPomSPYP3e5O1Es4VTmEUnaULmMWwN9hog5IZ4OTmmzmJjykeA++
4MfYPMa3fPR3Kr5oCMHIv93wo56HJ1gWFv0vcdR24rXEOhM5Y90g2hQWdQrAWp1a
fPhZOum091S3KO56gS3ZTito15B8F4S0hMBkHNRiVkYQZ0Ugk0qqqIDofivq8Iz1
d4Fiydw+1epQ/V0KwBcgBOPYZ5ihSY10YVtOZ/tCpxxdZ8GaUx3fzeatPCLnUz9C
C8Du/MD7BEKl7XbyqT8xF5gRHNIOfOLRm2TcBciO6NA6zPekN+hfq9chWDqFdyxz
mbxfeVOHCOLBDTrtxjmpfCUUT0pNf/E/2/22mb5U/m+eds0mv2cyp9tFJW3YT5cK
G2yC6peU952qJQ7M0dPaQYcvzOtePETUDxASP7ySl40ct8d+krb7iuK3I3rk98E1
o/0umSyJHBPS34WrB2wKHFxLRnTqDaJLfXC3kWKer0j0GOYxhL7oWKtxOYnjVuHu
lWHJC0J8xZnJMVq82JaZmIosrZjqUvCTEr8OrkD1P4+2x9Cw+bMuub3SzEWFiHdN
nZ6Th29m44GzyryW1MCiIAMal43OeuzwNLAr3MYZDxuX9N4hVlGM3cS6uH9Nti0S
6xOiDydIcFq0AFGoo+wgG+1hK2vY5VPKhZW6tE+bg3gTRZwqhjaeH54/WiUnLjjZ
wISaQSQLWYnlPUDx3VMJIvjQG6o4tejeiNPhSWRiFNNvDYlk3WowfvdTlFUZs8jG
gwoQLYvNyHUYSkFWiSFSfCcHSNb6StlvjoH8r1A/Q7GBVwy0R2Dr7zJiaCaSYB8z
inW+XvHUSSO0VqxETBOS0iRsF1TiT0L8vQoQhFig5/VYBwI8xOLAY3aE3dIjspxN
o9scO3eTcwDktf/biZ5vdefn5YXfIka1YWUSaKn6V5ai+iTL/1In+etWsLUu4hsi
g377LIZPsAlouDzoEqg8R6nAu28pYKtwhXKz1vpKwrMGIKaEwJnEjEsX4tYlR53o
bokCq+TkA4RWyM5Sqgjk/Vx1qtmQEpdDRJLX4BghJ9faq7grnIMBnvvGHEvr4Zgl
BSUfM47U6vhoL/4XH1NYLdf/aV4aAWPU9YUDr6TtxbpXXNP1grC7Igz/fP42DA57
ITb4F9LJ2ga7mPRb1P7rXsnaRSxjlq908wVjLbLgZ0IlPZ1RAcdWNISDlNpwW4ZW
1QMYBeN/ZhSMDhfBMUpyNd3oolumEPTEIZf4GqfmFUru7qmRpVGF2t7Fl7haETrV
oap2CnArpEMkqJJ1Peka6jDSv6CxKLKYMdhsOiRzqadCHqGqibgX8UjUSt3EcmOz
KZ4cSfrnyHK1RxCxzyJ/XaOPboDGegJLPqFih2SUJwna7260zBnug7WsA5gxCryZ
UeSBVU8vNCPBe44hxgcvPHHVIe7P3FYgQqV8U1jwurluoUC6bEcGtePIh1l/TRQf
JbHmwgVrryabNtrbd92KXpSJdng+62lXL/kQsUKvw3OPA0yJ2sQ0pVfjis0p+7yJ
WZiuREEcW0NP241vxOQTBp06KvMTf6ocfgQknrb5acuYNfzfLSfKEB55Z0INvzP7
sgfFbR9XAn7VhUsUdo8sJDxAIg5706R6DYONd+/L9ZUPScrG/tbSa244Ta3YmULP
VF/o58YsFHHxSZyM95BHzSkwjvLvL8nYy8Pp/P6bpBhiEtendwMiqRLD7vAHBkCC
kZ3I1AvHg7aNWRwFum/KXu7xJlp9ZiXMiXeyTpxWf70IMJU+XxIBoTIbWi5vB7KQ
8gUZSQI0fY1KGxC9+v3neFuRAjkcONQdE3Td1jYx4faiz0NU+xnZ4eRBK3WuFGVw
8oRxrDft1B0WrJofJmvouLNWtfbKTorVFeTN+1iS3ypdUnvLcsuvMcd7GIed/fIl
yEheM4+IXBX+X3mFhl+psR4liP3e4z+Dd8F7PqWam2NXRIurw9ZqE+AIl79LyYAo
R7k7JicDt0T2B7GUwBNxI0AZwCWccBUGb9OcFQbsLziEhPFZxNkF2fnuM0S81G8T
gtfO49I75UggCvlsH8HplacJkXbxv7u1WAObpLEncT8jZbP5MQiVzi29dlLEwUx9
/zNsasku1643tOZ0vIq0K7+vLA/EwfolQJ17En0kgqevJonGuUpR00E/22zWz1+U
6tKc7kKB27Im2zCbxMvW7nBVB0YE3firUXdeQl3TVEbvO9y0YWF2rmDw3jrQ4618
i1xu468rb4AfAsyJvnVBEzO/tTM2vvnsTY0m1X324Az+idNyvV2HbNLHuAm6WDVm
HPRTZ8Dqs0SjcMf/L1WPyZ6q7uFSJfbBik8smp3oWFvkxqtQR3TUL0saA4Juua8Q
cvK84QN+K+B+8DGIB68NbA5VXRXA7jV5DHPlGBbSuFYS1Yghx8yoCotpRjQaxTjl
4wBIAHctnmgWOKo4+b4iTJRYDqrAdDyi
=gVvr
-----END PGP MESSAGE-----
Can you decrypt this for us?

Thanks
David
Stef Walter
2015-03-23 19:13:31 UTC
Permalink
Sorry about the encrypted email ... I hit the wrong button.
Post by Shawn Landden
Post by Kay Sievers
Post by Stef Walter
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.
Even systemd can't reliably consume its own DBus timedated interface
remotely. Even once timedatectl is fixed, the information will be wrong
unless the version of zoneinfo and glibc are identical on both systems
involved.

This is hardly Cockpit specific.
Post by Shawn Landden
Post by Kay Sievers
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.
The timezone timedated provides is in presentation format (ie:
"Australia/Tasmania"), a non-standard identifier, rather than a actual
information about the timezone. Unless all systems agree on these names
and have identical versions of the data (ie: zoneinfo), identical
algorithms for interpreting it (ie: glibc) it is impossible to correctly
interpret it remotely.

There are several DBus interfaces that possible not remotable, whether
intentionally or not.

For example NetwortkManager has byte[4] arrays stored in uint32's that
are completely unusable on a different architecture ... other DBus
interfaces have local file names as properties ... as so on.

We should mark the timedated interface as non-remotable or call out the
remotability problems in the documentation.
Post by Shawn Landden
Post by Kay Sievers
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.
With the current DBus interface, the only way to reliably fix this is to
exec timedatectl remotely on the other system and pipe the output data.
See above.

Stef
Shawn Landden
2015-03-23 20:03:51 UTC
Permalink
Post by Stef Walter
Sorry about the encrypted email ... I hit the wrong button.
Post by Shawn Landden
Post by Kay Sievers
Post by Stef Walter
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.
Even systemd can't reliably consume its own DBus timedated interface
remotely. Even once timedatectl is fixed, the information will be wrong
unless the version of zoneinfo and glibc are identical on both systems
involved.
This is hardly Cockpit specific.
Post by Shawn Landden
Post by Kay Sievers
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.
"Australia/Tasmania"), a non-standard identifier, rather than a actual
information about the timezone. Unless all systems agree on these names
and have identical versions of the data (ie: zoneinfo), identical
algorithms for interpreting it (ie: glibc) it is impossible to correctly
interpret it remotely.
all that would be required would be a hash of the zoneinfo file
Post by Stef Walter
There are several DBus interfaces that possible not remotable, whether
intentionally or not.
For example NetwortkManager has byte[4] arrays stored in uint32's that
are completely unusable on a different architecture ... other DBus
interfaces have local file names as properties ... as so on.
We should mark the timedated interface as non-remotable or call out the
remotability problems in the documentation.
The problem really isn't this bad. With my patch to actually use the
remove timezone setting things are relatively OK. as is documented in
tzset() glibc falls back to UTC.
Post by Stef Walter
Post by Shawn Landden
Post by Kay Sievers
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.
With the current DBus interface, the only way to reliably fix this is to
exec timedatectl remotely on the other system and pipe the output data.
See above.
Stef
--
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com
Tom Gundersen
2015-03-24 12:59:40 UTC
Permalink
Post by Stef Walter
Sorry about the encrypted email ... I hit the wrong button.
Post by Shawn Landden
Post by Kay Sievers
Post by Stef Walter
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.
Even systemd can't reliably consume its own DBus timedated interface
remotely. Even once timedatectl is fixed, the information will be wrong
unless the version of zoneinfo and glibc are identical on both systems
involved.
Could you explain this? Is not the ABI stable here? Surely
zoneinfo/glibc are backwards compatible and do not require being
upgraded in lock-step, so how exactly does this break?
Post by Stef Walter
Post by Shawn Landden
Post by Kay Sievers
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.
"Australia/Tasmania"), a non-standard identifier, rather than a actual
information about the timezone. Unless all systems agree on these names
and have identical versions of the data (ie: zoneinfo), identical
algorithms for interpreting it (ie: glibc) it is impossible to correctly
interpret it remotely.
These names are backwards compatible API, right? If zoneinfo changes
the names it uses we are in trouble as we currently symlink
/etc/localtime to whatever the zonefile is. So if these files change
names on upgrades we end up with a dangling symlink.

Also the format of the zoneinfo files, how is that ambiguous?

I can understand the actual data may be out-of-sync, but the formats
should all be fine, no?
Post by Stef Walter
There are several DBus interfaces that possible not remotable, whether
intentionally or not.
For example NetwortkManager has byte[4] arrays stored in uint32's that
are completely unusable on a different architecture ... other DBus
interfaces have local file names as properties ... as so on.
We should mark the timedated interface as non-remotable or call out the
remotability problems in the documentation.
Post by Shawn Landden
Post by Kay Sievers
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.
With the current DBus interface, the only way to reliably fix this is to
exec timedatectl remotely on the other system and pipe the output data.
See above.
Stef
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Zbigniew Jędrzejewski-Szmek
2015-03-24 13:15:15 UTC
Permalink
Post by Tom Gundersen
Post by Stef Walter
Sorry about the encrypted email ... I hit the wrong button.
Post by Kay Sievers
Post by Stef Walter
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.
Even systemd can't reliably consume its own DBus timedated interface
remotely. Even once timedatectl is fixed, the information will be wrong
unless the version of zoneinfo and glibc are identical on both systems
involved.
Could you explain this? Is not the ABI stable here? Surely
zoneinfo/glibc are backwards compatible and do not require being
upgraded in lock-step, so how exactly does this break?
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".

If we go to the trouble of displaying the remote local time, imho we
should do it as the remote does.
Post by Tom Gundersen
Post by Stef Walter
Post by Kay Sievers
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.
"Australia/Tasmania"), a non-standard identifier, rather than a actual
information about the timezone. Unless all systems agree on these names
and have identical versions of the data (ie: zoneinfo), identical
algorithms for interpreting it (ie: glibc) it is impossible to correctly
interpret it remotely.
I can understand the actual data may be out-of-sync, but the formats
should all be fine, no?
I'd think so.

Zbyszek
Stef Walter
2015-03-24 13:31:17 UTC
Permalink
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Stef Walter
2015-03-24 13:40:15 UTC
Permalink
/me hates the new thunderbird-enigmail
Post by Zbigniew Jędrzejewski-Szmek
Post by Tom Gundersen
Post by Stef Walter
Sorry about the encrypted email ... I hit the wrong button.
Post by Kay Sievers
Post by Stef Walter
Post by Kay Sievers
Post by David Herrmann
Hi
On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
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!
Post by Lennart Poettering
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.
Even systemd can't reliably consume its own DBus timedated interface
remotely. Even once timedatectl is fixed, the information will be wrong
unless the version of zoneinfo and glibc are identical on both systems
involved.
Could you explain this? Is not the ABI stable here? Surely
zoneinfo/glibc are backwards compatible and do not require being
upgraded in lock-step, so how exactly does this break?
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".
If we go to the trouble of displaying the remote local time, imho we
should do it as the remote does.
Right exactly.

So for Cockpit, because it now looks like timedated won't include what
we need, we'll just exec this on the remote system:

/usr/bin/date '+%s:%:z'

This essentially runs the remote system's glibc with the remote zoneinfo
to calculate the local time offset. It seems dirty, but once you factor
in $TZ, tzset(), etc. it isn't *that* bad.

Similarly (unless timedated grows a whole bunch more properties about
the current timezone) 'timedatectl status' and 'timedatectl
list-timezones' should just exec itself on the remote system.
Post by Zbigniew Jędrzejewski-Szmek
Post by Tom Gundersen
Post by Stef Walter
Post by Kay Sievers
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.
"Australia/Tasmania"), a non-standard identifier, rather than a actual
information about the timezone. Unless all systems agree on these names
and have identical versions of the data (ie: zoneinfo), identical
algorithms for interpreting it (ie: glibc) it is impossible to correctly
interpret it remotely.
I can understand the actual data may be out-of-sync, but the formats
should all be fine, no?
I'd think so.
Indeed.

Stef
Kay Sievers
2015-03-24 14:11:00 UTC
Permalink
On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".
If we go to the trouble of displaying the remote local time, imho we
should do it as the remote does.
No, we should care about the *state* of the system, and that is its
time value and its configured location on earth.

Systemd has no business in "fixing" the *presentation* logic of these
values. It is not an API for the timezone database. These tools
already exist.

Please stop trying to add insufficient and half-thought-through APIs
to cover problems which just do not exist in reality or do not need to
be worked-around by systemd.

Thanks,
Kay
Stef Walter
2015-03-24 14:17:05 UTC
Permalink
Post by Kay Sievers
On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".
If we go to the trouble of displaying the remote local time, imho we
should do it as the remote does.
No, we should care about the *state* of the system, and that is its
time value and its configured location on earth.
Then stop displaying incorrect "presentation" data in timedatectl.
Post by Kay Sievers
Systemd has no business in "fixing" the *presentation* logic of these
values. It is not an API for the timezone database. These tools
already exist.
Please stop trying to add insufficient and half-thought-through APIs
to cover problems which just do not exist in reality or do not need to
be worked-around by systemd.
This gives us what we need:

$ date '+%s:%:z'

So we'll use that instead of timedated. I'll update the wiki page for
the timedated DBus interface to note parts of it are just not remotable.

Stef
Tom Gundersen
2015-03-24 14:22:21 UTC
Permalink
Post by Stef Walter
Post by Kay Sievers
On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".
If we go to the trouble of displaying the remote local time, imho we
should do it as the remote does.
No, we should care about the *state* of the system, and that is its
time value and its configured location on earth.
Then stop displaying incorrect "presentation" data in timedatectl.
I don't see how this is incorrect now. See below.
Post by Stef Walter
Post by Kay Sievers
Systemd has no business in "fixing" the *presentation* logic of these
values. It is not an API for the timezone database. These tools
already exist.
Please stop trying to add insufficient and half-thought-through APIs
to cover problems which just do not exist in reality or do not need to
be worked-around by systemd.
$ date '+%s:%:z'
So we'll use that instead of timedated. I'll update the wiki page for
the timedated DBus interface to note parts of it are just not remotable.
For the record, I think it IS remoteable now with the recent change.
It all comes down to what you intend the fields to mean. Now we mean
the field to mean "the real localtime of the server (as seen from the
client)", whereas you want it to mean "the localtime the server thinks
it has". If these two notions don't coincide, something is obviously
fucked, but I don't think it is correct to say that the current way of
handling it mean the API is not remotable.

Cheers,

Tom
Stef Walter
2015-03-24 14:40:56 UTC
Permalink
Post by Tom Gundersen
Post by Stef Walter
Post by Kay Sievers
On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".
If we go to the trouble of displaying the remote local time, imho we
should do it as the remote does.
No, we should care about the *state* of the system, and that is its
time value and its configured location on earth.
Then stop displaying incorrect "presentation" data in timedatectl.
I don't see how this is incorrect now. See below.
Post by Stef Walter
Post by Kay Sievers
Systemd has no business in "fixing" the *presentation* logic of these
values. It is not an API for the timezone database. These tools
already exist.
Please stop trying to add insufficient and half-thought-through APIs
to cover problems which just do not exist in reality or do not need to
be worked-around by systemd.
$ date '+%s:%:z'
So we'll use that instead of timedated. I'll update the wiki page for
the timedated DBus interface to note parts of it are just not remotable.
For the record, I think it IS remoteable now with the recent change.
It's better.
Post by Tom Gundersen
It all comes down to what you intend the fields to mean. Now we mean
the field to mean "the real localtime of the server (as seen from the
client)", whereas you want it to mean "the localtime the server thinks
it has".
The latter is the only place where "server local time" is relevant. The
server's UTC time is the one that you can reason about, and display as
"client local time" ... in cases where you want to do that.

But when you're displaying "server local time" it should be according to
the server's zoneinfo.

For example in Cockpit (which again runs in a web browser) when you see:

Server time: 2015-03-24 21:53
Time zone: Australia/Tasmania

It means "the current time that the server thinks it is" ... not the
time the browser thinks it is ... not the time the browser thinks the
server should think it is ... But actually the time on the server, as
interpreted by the server.

Yes, I realize this is "presentation" data ...
Post by Tom Gundersen
If these two notions don't coincide, something is obviously
fucked,
That's the thing. It's not fucked. There will never be a time when all
zoneinfo's (and copies of moment-timezone.js [0] in our case) laying
around are identical.

But again, If you want to say this is out of scope of systemd, fine.
We'll just use the glibc linked into the remote /usr/bin/date to
interpret the *remote* zoneinfo for us, rather than the glibc linked
into timedated. It's a shame we have to spawn two processes instead of
one ... but so be it.

Stef
Simon McVittie
2015-03-24 15:16:22 UTC
Permalink
Post by Stef Walter
Post by Tom Gundersen
It all comes down to what you intend the fields to mean. Now we mean
the field to mean "the real localtime of the server (as seen from the
client)", whereas you want it to mean "the localtime the server thinks
it has".
The latter is the only place where "server local time" is relevant.
Perhaps it would be instructive to think about why the server's local
time is of any interest?

My guess would be that it's to answer questions like "how long do I have
before that cron job starts?" or "how long ago did that daemon log this
warning?", which AFAICS are, as Stef says, about the local time the
server thinks it has, and not about the local time that the client
thinks the server should have.

S
Kay Sievers
2015-03-24 14:23:36 UTC
Permalink
Post by Stef Walter
Post by Kay Sievers
On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".
If we go to the trouble of displaying the remote local time, imho we
should do it as the remote does.
No, we should care about the *state* of the system, and that is its
time value and its configured location on earth.
Then stop displaying incorrect "presentation" data in timedatectl.
Isn't it fixed with Shawn patch?
Post by Stef Walter
Post by Kay Sievers
Systemd has no business in "fixing" the *presentation* logic of these
values. It is not an API for the timezone database. These tools
already exist.
Please stop trying to add insufficient and half-thought-through APIs
to cover problems which just do not exist in reality or do not need to
be worked-around by systemd.
$ date '+%s:%:z'
So we'll use that instead of timedated. I'll update the wiki page for
the timedated DBus interface to note parts of it are just not remotable.
Which parts are not not-remotable? You get the exact values you need
for a machine, it's current time and location.

Kay
David Herrmann
2015-03-24 14:11:55 UTC
Permalink
Hi

On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
[...]
Post by Zbigniew Jędrzejewski-Szmek
Post by Tom Gundersen
Post by Stef Walter
Post by Kay Sievers
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.
Even systemd can't reliably consume its own DBus timedated interface
remotely. Even once timedatectl is fixed, the information will be wrong
unless the version of zoneinfo and glibc are identical on both systems
involved.
Could you explain this? Is not the ABI stable here? Surely
zoneinfo/glibc are backwards compatible and do not require being
upgraded in lock-step, so how exactly does this break?
Exactly because they do not require being upgraded in lock-step, doing
conversion to the local time locally is "racy". Assuming we have up-to-date
timezone database locally, with the patch that was merged today we can
answer the question "what the local time should be remotely", but not
necessarily "what the local time is remotely".
...and if the remote host-name contains unicode characters our local
host cannot display, should we also transfer the font?

If you local timezone data is out-of-date, it's your problem. Update
it and you get the correct data. Besides, if we assume both DBs are
different, who says that you're interested in the data from the remote
host? If your local host has an old (or newer?) timezone DB, then you
explicitly want to use this. So your view of the timedata should
depend on your local configuration, not on the remote.

Thanks
David
Shawn Landden
2015-03-23 11:44:57 UTC
Permalink
Also allow getting time from time(2) when BUS_TRANSPORT_MACHINE.

v2: check for error
---
src/timedate/timedatectl.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9e04f8f..44d329e 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -106,14 +106,21 @@ static void print_status_info(const StatusInfo *i) {

/* Enforce the values of /etc/localtime */
if (getenv("TZ")) {
- fprintf(stderr, "Warning: Ignoring the TZ variable. Reading the system's time zone setting only.\n\n");
+ fprintf(stderr, "Warning: Ignoring the TZ variable.\n\n");
unsetenv("TZ");
}

+ r = setenv("TZ", i->timezone, false);
+ if (r < 0) {
+ log_error_errno(errno, "Failed to set TZ environment variable: %m");
+ exit(EXIT_FAILURE);
+ }
+ tzset();
+
if (i->time != 0) {
sec = (time_t) (i->time / USEC_PER_SEC);
have_time = true;
- } else if (arg_transport == BUS_TRANSPORT_LOCAL) {
+ } else if (IN_SET(arg_transport, BUS_TRANSPORT_REMOTE, BUS_TRANSPORT_MACHINE)) {
sec = time(NULL);
have_time = true;
} else
--
2.2.1.209.g41e5f3a
Kay Sievers
2015-03-24 12:47:19 UTC
Permalink
Post by Shawn Landden
Also allow getting time from time(2) when BUS_TRANSPORT_MACHINE.
v2: check for error
Applied.

Thanks,
Kay
Lennart Poettering
2015-04-02 09:55:35 UTC
Permalink
Post by Shawn Landden
Also allow getting time from time(2) when BUS_TRANSPORT_MACHINE.
v2: check for error
---
src/timedate/timedatectl.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9e04f8f..44d329e 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -106,14 +106,21 @@ static void print_status_info(const StatusInfo *i) {
/* Enforce the values of /etc/localtime */
if (getenv("TZ")) {
- fprintf(stderr, "Warning: Ignoring the TZ variable. Reading the system's time zone setting only.\n\n");
+ fprintf(stderr, "Warning: Ignoring the TZ variable.\n\n");
unsetenv("TZ");
}
+ r = setenv("TZ", i->timezone, false);
+ if (r < 0) {
+ log_error_errno(errno, "Failed to set TZ environment variable: %m");
+ exit(EXIT_FAILURE);
No! Please never use exit() as a replacement for proper error
handling. In fact, exit() is never OK in our sources really. I have
added a section to CODING_STYLE now to explain this.
Post by Shawn Landden
+ }
+ tzset();
+
if (i->time != 0) {
sec = (time_t) (i->time / USEC_PER_SEC);
have_time = true;
- } else if (arg_transport == BUS_TRANSPORT_LOCAL) {
+ } else if (IN_SET(arg_transport, BUS_TRANSPORT_REMOTE, BUS_TRANSPORT_MACHINE)) {
THis makes no sense, the check is reversed, no? Why change this at
all?

Lennart
--
Lennart Poettering, Red Hat
Loading...