Timezones, Dayparting and Schedule Accuracy

If a schedule fires an hour early, a day late, or works in summer and breaks in winter, you are looking at a timezone problem. There are three clocks involved and they do not have to agree.

The three clocks

Your account’s timezone in easyCMS, what you see when you read the schedule.
The display’s timezone: set per display in easyCMS.
The device’s own clock: the operating system time on the player hardware.

A schedule is stored against one of these and evaluated against another. Getting a predictable result means deciding, deliberately, which one you want to be authoritative.

Run at CMS time

Every scheduled event has a run at CMS time option, and it is the setting that decides the whole behaviour:

On: the event fires at the time as read on the CMS clock, regardless of where the display physically is. A 09:00 event happens at 09:00 CMS time everywhere. Use this when a campaign must go live simultaneously across a country or a continent.
Off: the event fires at 09:00 local to each player. Use this for opening hours, lunch menus, and anything that should follow the local day.

Most confusion comes from expecting local behaviour while the event is set to CMS time, or the reverse. For a single-site network in one timezone the two are identical, which is why the problem only appears when you add your second country.

Set the display timezone

Per display in easyCMS, set the timezone to where the screen physically is. This is what the CMS uses to interpret local-time events and to show you accurate “last seen” times. A display left at the default sits in your timezone as far as the CMS is concerned, no matter where it is plugged in.

Set the device clock correctly

The device must also have the right time, from an internet time server, with the right timezone selected in the operating system. A wrong device clock will:

Fire local-time schedules at the wrong moment.
Break secure connections to the CMS entirely if it is far enough out, an unexplained “cannot connect” on a brand-new player is often just a clock set to 2010.

Enable automatic time on the device and confirm the timezone in the device’s own settings, not only in easyCMS.

Daylight saving

Both the device operating system and the CMS handle daylight saving automatically if they are set to a named timezone (Europe/Warsaw) rather than a fixed offset (UTC+1). Fixed offsets are the reason schedules drift by an hour twice a year. Always pick the named city, never the offset.

Dayparts

Dayparts are named time bands, “Opening”, “Lunch”, “Evening”, that you schedule against instead of typing times repeatedly. They inherit the same CMS-time versus player-time rule as any other event, so check that setting on the event using the daypart, not on the daypart itself.

Two practical notes:

A daypart that crosses midnight needs care; verify it in the agenda view before relying on it.
Changing a daypart changes every event that uses it, retroactively. That is the point of them, but it makes a small edit have a large blast radius across a big network.

Verify before you trust it

Open the Schedule in agenda view, pick the display, and read what is actually active at the time you care about. The agenda view resolves priority, dayparting and timezone for you, and it is the only view that answers “what will this screen show at 3pm on Thursday” honestly.