Maybe you need to update tlsdate's D-Bus bus cnofig file?
https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/master/dbus/org.torproject.tlsdate.conf.in

Spec: https://dbus.freedesktop.org/doc/dbus-daemon.1.html

#2: I looked at that, but it's not obvious to me why it would be preventing non-Chromium processes from observing its signals. I didn't see the signals when I ran dbus-monitor as chronos or as root, too.

Perhaps, Chrome neither receives the TimeUpdated signal, but it's updating the system tray's clock because it receives other signals/events?
Did you check that Chrome actually is receiving the TimeUpdated signal?

That's a good question, although it still doesn't explain why I wasn't seeing the signals in dbus-monitor, since the code that's emitting them looks fine to me. :-)

Igor, when you were looking at this did you verify that Chrome was seeing the signals or just that it was updating the system tray?

It was receiving the signal. I even had a CL based on that - unfortunately deleted now.

I was testing by starting the system without network and checking the logs. The moment I was connecting the network, the tsldated would update the time and the function that was listening to the event was called.

You mean, SystemClockClientImpl::TimeUpdatedReceived() is actually called?

That's right, assuming SystemClockClientImpl was initialized.

Basically I had it working in two implementations:
One where I've used DBusThreadManager::Get()->GetSystemClockClient() and adding code in TimeUpdatedReceived(dbus::Signal* signal) from SystemClockClientImpl to receive the event where I needed.

In the other case I've used the bus object in SessionManagerClient::Init to create an ObjectProxy and connect to signal from tlsdated (using the same code as we have in Init from SystemClockClientImpl). This implementation also worked and I was receiving TimeUpdated event when time sync was done.

In the second implementation the TimeUpdatedReceived was not triggered in SystemClockClientImpl because it wasn't initialized IIRC.

I'm not seeing this in a recent caroline build. When I run:

  dbus-monitor --system 'path=/org/torproject/tlsdate'

as root and then run "restart tlsdated", I see the following:

signal time=1531957298.000585 sender=:1.575 -> destination=(null destination) serial=8 path=/org/torproject/tlsdate; interface=org.torproject.tlsdate; member=TimeUpdated
   string "system-clock"
signal time=1531957300.000799 sender=:1.575 -> destination=(null destination) serial=9 path=/org/torproject/tlsdate; interface=org.torproject.tlsdate; member=TimeUpdated
   string "network"

Issue 860442 describes problems with observers in Chrome apparently currently not receiving the signal. I'm not sure if it's related.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/7c67bde6c3e9b505975b2933a259db8c3b661a47

commit 7c67bde6c3e9b505975b2933a259db8c3b661a47
Author: Daniel Erat <derat@chromium.org>
Date: Fri Jul 20 03:12:54 2018

tlsdate: Let tlsdated send to its own D-Bus interface.

org.torproject.tlsdate.conf contains the following stanza:

  <policy context="default">
    <deny send_interface="org.torproject.tlsdate" />
    ...
  </policy>

This appears to apply to the "tlsdate" user that's used to
run tlsdated. For reasons that are unclear to me, with this
stanza, I'm able to observe TimeUpdated D-Bus signals when
running dbus-monitor as the root user, but Chrome doesn't
receive them. It's not clear to me if this behavior is
deterministic or whether it's changed over time.

This change adds an "allow send_interface" directive to the
user="tlsdate" stanza at the top of the file, which results
in Chrome receiving TimeUpdated signals as expected.

BUG=chromium:860442, chromium:661205 
TEST=made chrome log when receiving TimeUpdated and verified
     that signals are received at boot for "system-clock"
     and "network"

Change-Id: I36950a5da78fd18fcb3883b088f60d641d2bddb8
Reviewed-on: https://chromium-review.googlesource.com/1142825
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[modify] https://crrev.com/7c67bde6c3e9b505975b2933a259db8c3b661a47/dbus/org.torproject.tlsdate.conf.in

Let me know if you still see problems here.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/cfb5d5ce4460af66d3b24f49697f515d7a9de88a

commit cfb5d5ce4460af66d3b24f49697f515d7a9de88a
Author: Daniel Erat <derat@chromium.org>
Date: Mon Jul 23 18:23:35 2018

tlsdate: Let tlsdated send to its own D-Bus interface.

org.torproject.tlsdate.conf contains the following stanza:

  <policy context="default">
    <deny send_interface="org.torproject.tlsdate" />
    ...
  </policy>

This appears to apply to the "tlsdate" user that's used to
run tlsdated. For reasons that are unclear to me, with this
stanza, I'm able to observe TimeUpdated D-Bus signals when
running dbus-monitor as the root user, but Chrome doesn't
receive them. It's not clear to me if this behavior is
deterministic or whether it's changed over time.

This change adds an "allow send_interface" directive to the
user="tlsdate" stanza at the top of the file, which results
in Chrome receiving TimeUpdated signals as expected.

BUG=chromium:860442, chromium:661205 
TEST=made chrome log when receiving TimeUpdated and verified
     that signals are received at boot for "system-clock"
     and "network"

Change-Id: I36950a5da78fd18fcb3883b088f60d641d2bddb8
Reviewed-on: https://chromium-review.googlesource.com/1142825
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
(cherry picked from commit 7c67bde6c3e9b505975b2933a259db8c3b661a47)
Reviewed-on: https://chromium-review.googlesource.com/1147021
Reviewed-by: Dan Erat <derat@chromium.org>
Commit-Queue: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/cfb5d5ce4460af66d3b24f49697f515d7a9de88a/dbus/org.torproject.tlsdate.conf.in