I’m seeing some peculiar behaviour with SOSE around the timing of when assets are displayed. For instance, an asset shows beyond the time specified in the schedule. This got me wondering whether it was a timezone /daylight saving problem. Of course, it could be user error, but I’m not seeing quite why just now.
The logs in balena show the correct time for the screen UTC + 1 (for British Summer Time) but when you run date at the command line it returns UTC only.
How can I check that SOSE is definitely configured with the correct timezone and daylight saving adjustment? Or is that just a given?
pi@rpi300we:~ $ timedatectl
Local time: Wed 2019-09-18 19:15:58 EDT
Universal time: Wed 2019-09-18 23:15:58 UTC
RTC time: n/a
Time zone: America/New_York (EDT, -0400)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
root@c5ee636:~# timedatectl
Local time: Sat 2019-09-21 21:03:10 UTC
Universal time: Sat 2019-09-21 21:03:10 UTC
RTC time: n/a
Time zone: n/a (UTC, +0000)
System clock synchronized: yes
NTP service: n/a
RTC in local TZ: no
This would suggest that the local time zone is not being observed, owing to no NTP being available.
Is this normal for SOSE or does it normally find a NTP service and syncronise itself?
As far as I know, Screenly doesn’t control/change your NTP configuration during installation since it is up to the person installing the system to configure that.
If you want to configure it in your Screenly device, do the following:
Use the raspi-config method to set up the time/date info: sudo raspi-config
Option 4 > then 1 and 2 should be configured properly.
Then…
Open the config file: sudo nano /etc/systemd/timesyncd.conf
Edit it so that there are no #'s in front of the following:
[Time]
NTP=0.north-america.pool.ntp.org
The above is simply how I have mine set up so that it syncs with the ntp.org north american server farm.
Then, restart the service and check the status (or simply reboot the Screenly pi). sudo systemctl restart systemd-timesyncd.service sudo systemctl daemon-reload sudo systemctl status systemd-timesyncd.service
With regards to Balena, For the Host OS, you can configure it this way:
I see that they advised you to use the ENV TZ=Europe/London (or whatever timezone you are at) on your Dockerfile… did you try this? if so, did it fix the issue?
I also tried the timezone variable and that didnt work…
I created a balena app with pi zero and installed screenly… i ran cmd timedatectl set-timezone America/New_York
then i checked via date, and timedatectl again
then i added the asset https://www.time.gov/
then it went to that page and correctly displayed the time… but then i restarted the docker instance and all those settings went kaputz…
so we need to set the environment timezone via the hostOS as you’re saying cause I am not about to start recreating the docker image again just to change that timezone setting…
or maybe just put in the dockerfile timedatectl set-timezone Europe/London
and it’ll always set the docker instance to that… might be easier than trying to mess with the hostOS since it is mostly read only and very annoying to mess with as you know…
So…I deployed another screenly device in balena using the latest screenly version. timedatectl in the hostos reports UTC + 0, no timezone adjustment despite applying timezone variables.
However, running date in screenly-server returns:
Mon Oct 21 17:52:27 BST 2019
This is different to the slightly older screenly one version I have been working on up until this point. So screenly appears to be (in my case), correctly calibrating itself timezone wise. I don’t need to know how it’s doing so though I wonder if a manual override, available in the UI might be sensible.
Screenly appears to calibrating itself based on the environment variable configuration in balena as specified over on the balena fourm. The correct environment variable (for me at least) is TZ, value Europe/London.
When the environment variable is adjusted, the screenly services are restarted and correctly calibrate the time based on the environment variable value.
@lstocky so setting the device environment variable to TZ instead of TIMEZONE worked after a restart/reboot of the device (hostOS and main) ? if so, this means someone needs to make adjustments to this: https://github.com/balena-io-playground/balena-timezone right?
and i also saw this pull request from rusko:
which he states that he is making the container sync with the hostOS and it seems in your case and maybe everyone else’s, that is not the desired default setting right?
it seems in your case and maybe everyone else’s, that is not the desired default setting right?
Right, in my case the hostOS timezone is not easily configured and I am relying on the fact that the screenly-server app is deriving it’s timezone configuration from the environment variable. The above sync is ok so long as the environment variable has precedence over the sync behaviour.
