Skip to main content

MagicINFO schedule plays at the wrong time: fix the clock

Schedules run on each display's own clock, in the display's own time zone, and the server only ever sends displays UTC. Fix the display's time zone and daylight-saving (DST) settings: changing the server's time zone does nothing for the screen.

Symptoms​

  • Content starts or stops an hour early or late, often only after a DST change.
  • Content is several hours off all day.
  • In the evening, the screen suddenly shows the next day's content.
  • On/off timers fire at the wrong time.
  • The device's Time tab says that the current time cannot be set and asks you to set the time zone.

How time reaches the screen​

  • The server sends UTC only. Every 30 minutes, and at each full check-in, the display asks the server for the time. The answer is UTC with no time zone attached.
  • The display adds its own offset. It applies its own time-zone setting and its own DST rule, then sets its clock. Some display client versions also switch the clock to manual mode at that point, so an internet-time (NTP) setting made in the display's own menu may not survive while MagicINFO manages the display.
  • Publishing carries no time. Schedule events hold local start and end times, and the display compares them with its own clock.
  • A new local date means a new day. The moment the display's local date changes, it builds and plays that day's schedule. A clock that jumps forward past midnight therefore plays tomorrow's content immediately.
  • The server's time zone only affects server-side records, such as logs, reports, last-connection times and reserved jobs.

A display's time zone and DST change only through one of these:

  • the display's own menu
  • the device's Setup or Time tab in MagicINFO
  • a preset
  • the server-wide Automatic Time Zone (S-Player) setting

About Automatic Time Zone​

This server setting pushes one zone to displays at check-in. It is read from the server-level settings only, with no per-organisation override. It reaches only displays that do not support presets and are not Lite players. On a server with screens in more than one time zone, any single value is wrong for someone, so leave it off and set zones per device or by preset. Switching it off does not change any display back.

Fix​

  1. Leave the server clock alone. Look at the display instead.
  2. Check the zone. Open the device in MagicINFO, choose Edit, then Setup. Check the time zone (half-hour zones such as GMT-03:30 work) and whether DST is on.
  3. Check the DST rule. A manual DST rule holds a start and an end, each given as month, week, weekday and hour. Compare it with the real local rule. For example, DST in most of North America starts on the second Sunday in March, so a rule set to the first Sunday starts a week early. An error of exactly one hour around the changeover points here.
  4. Read the live clock. On the Time tab, click Current Status and compare the result with the real local time.
  5. Correct the setting on the device, or apply a preset to a group of devices. A zone or DST change makes the display ask for the time straight away, otherwise the next sync is at most 30 minutes away.
  6. Check clock elements inside your content. An analog clock element in a layout carries its own zone and DST options. Unless it is set to use the device's locale, it shows its own offset, whatever the screen's settings are.
  7. Does the clock jump at the same time every day? Write the time down in UTC as well as local time. Read the display's clock just after the jump, before anyone resets it, and check whether someone saved changes on the device's Time tab. Also check the display's own menu for timers or manual time settings.
tip

If you report a time problem to anyone, include the display's time zone, the DST setting and a clock reading taken at the moment it was wrong. "The server time" is never the useful number.

How to confirm it worked​

Current Status on the Time tab shows the correct local time. The next schedule change happens at the planned minute, and on/off timers follow it. After the next DST changeover, check once more that the screen moved by exactly one hour on the right date.

Checked against MagicINFO Server 21.1070 behaviour, October 2026.

Prefer not to run the server yourself? MiCloud hosts MagicINFO for you.

Last updated on