Screens evaluate their schedules locally, against their own clock. A screen whose clock is wrong runs your schedule at the wrong time, and nothing in the dashboard looks broken while it does.
How a screen gets the time
Over the network, from a time server, using NTP on UDP port 123.
That is why NTP appears in the network checks on a screen’s Details tab, and why a failing time check is reported as a scheduling problem rather than a networking curiosity.
If outbound NTP is blocked, point the screens at an internal time server instead. See Configure time servers.
The Raspberry Pi has no battery clock
A Raspberry Pi based Screenly Player has no hardware real-time clock, so it does not keep time while powered off. On boot it has no idea what time it is until it reaches a time server.
Normally that is a few seconds and nobody notices. It matters when a player reboots while the network is down: it comes back with no reliable time and cannot evaluate schedules correctly until the connection returns.
The Player Max has a real-time clock and keeps the correct time through a reboot with no network at all.
That is a genuine reason to prefer a Player Max on a site where power is less reliable than it should be.
When the clock breaks more than scheduling
A clock wrong by more than a few minutes also breaks TLS, because certificates are only valid between two dates. A device that thinks it is 2019 cannot connect to us at all, and presents as a screen that will not come online rather than as a clock problem. See Common setup issues.
Checking a screen’s time
A screen’s Overview tab shows its local time. That is the fastest check when scheduled content appears at the wrong hour: compare it against what the clock on the wall next to it says.
A screen an hour out is usually in the wrong time zone rather than genuinely wrong. See Time zones.