Screenly Forum

Viewing/Setting Timezone

Hi there,

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?

thanks
lstocky

in your console type:

timedatectl

you should see something like this:

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

Thanks @ealmonte32

This is what I get on the HostOS

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:

Thanks @ealmonte32.

I’m traveling this week, will take a look at this when I’m back :+1:t2:

Getting some really strange behaviour with balenaOS on this topic.

I figure it’s best addressed through the balena forums, here’s the link: https://forums.balena.io/t/chrony-and-ntp-raspberry-pi-configuration-weirdness/37029 for reference

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?

Yes, or thereabouts. I defined an environment variable via the balena dashboard - so the variable as TIMEZONE and the value Europe/London.

Let me know if you think I’m missing something.

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…

thanks @ealmonte32

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.

Actually, correction.

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.

That’s as good a solution as I need. :ok_hand:t3:

@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?

setting the device environment variable to TZ instead of TIMEZONE worked after a restart/reboot of the device

Correct.

this means someone needs to make adjustments to this: https://github.com/balena-io-playground/balena-timezone right?

Yes, I have made that suggestion on the thread in the balena forums.

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.