Hi, I’ve noticed in my build the etc/systemd/timesyncd.conf is empty. There also is no /var/lib/systemd/clock/ folder The issue I’m dealing with is the device seems to have the right NTP time, but the incorrect TZ. It’s been up for over 72 hours and I know the RPi’s clock should drift a bit, but it hasn’t yet. Separately, it looks like port 123 is blocked when I run netstat -ap. I followed this : https://docs.resin.io/runtime/runtime/#checking-if-device-time-is-ntp-synchronized and the error I get is dbus-send command not found
Hi, the time management happens in the host OS, not in the user application container. You are on the right track, but those files and services are in the host OS.
Here’s what we do for time management in a bit more detail (and we’ll be adding more info to it over time):
The dbus-send command doesn’t work for you because to use that, you have to install it in your user container (that’s not installed by default, because the base images are kept to minimal, the users chose what do they need). In case of Debian base images for example, it is provided by the dbus package. Afterwards you’ll be able to use that example command. We’ll make this even clearer in the documentation that you link to.
The devices are using UTC timezones by default (as it is a standard practice, and we cannot guess which timezones the devices will be deployed at 
). If you’d like to change the device time zone, you can probably use a similar Edit: looks previous suggestion wouldn’t work, as to be minimal, the dbus-send command to do that. You’d need to check with the documentation of timedated, as that’s the service to call, just like in the example.zoneinfo data is not installed in the host OS. On the other hand, to change time zone within your container (which is what should matter to you ultimately, you can check out the following example code (the gist is reconfiguring the operating system that is within the container):
Regarding port 123, are you looking for whether there’s a process listening on that port, or connecting out? There should be nothing listening because there’s no ntp server by default on the device.
Hope this will be useful!
Hi Gergely,
Thanks for your quick reply. I followed your resin-timezone repo and it works perfectly.
The Resin dashboard has approximate location and I know that can be masked due to VPNs, but it may be a cool feature to add recognized TZ based off location in the future.
To answer your p 123 question, I wanted to know if the ntp client was connecting out to pool.ntp.org or any other of the ntp servers, as the documentation suggests to check.
For any future readers my base rpi3 image is: resin/%%RESIN_MACHINE_NAME%%-node:latest
Thanks again!
Hi Sunil, the logs in the dashboard show the time according to your own location, so that should be good for one set of clarity. For the device’s own clock, we think that “servers” (which in our minds these devices are in most cases) should run on UTC for clarity, and if the users need differently, have an option to change that (as shown above) 
Regarding the port, I don’t think that the ntp process keeps that port open, once the time is synchronized, it will connect only occasionally, not keeping the connection open. I was trying on my local machine to catch timesyncd in the act with netstat, but couldn’t. systemctl status shows that the status is synchronized, though (on a resin.io device that should be checked in the hostOS, for example on a -dev machine).
Cheers!
13 posts were split to a new topic: Timezone setting in Alpine images