Timezones Across the Platform

signageOS has no single platform-wide timezone setting. Every time you read or enter belongs to one of three groups, depending on who acts on it:

• UTC for everything the cloud evaluates or records: alert rules, alert notifications, and REST API timestamps. UTC is also the default for dates in Box.
• Device local time for everything the device executes on its own: timers, scheduled power actions, and content schedules.
• A timezone you pick when you schedule a bulk action.

There is no company, organization, or location timezone. The only per-user setting is the timezone in your Box profile, and it applies to a few screens only (see Time in Box).

Quick reference

Where you see or enter a time	Timezone
Alert rule active time windows	UTC
Alert and alert rule dates in Box	UTC, labeled (UTC)
Alert email notifications	UTC, printed as GMT
REST API timestamps	UTC, ISO 8601 ending in Z
Timers, Native and Proprietary	Device local time
Scheduled power actions	Device local time
Device detail in Box: history, telemetry, uptime, screenshots, logs	Device timezone, labeled with its offset, e.g. (UTC+02:00)
Bulk action schedule	The timezone you select in the wizard
Everything else in Box: applets, bulk actions, policies, organizations	UTC, labeled UTC

Alerts

Active time windows are in UTC

The Active time windows of an Alert Rule are evaluated in UTC. They do not follow the timezone of your devices, your organization, your Box profile, or your browser, and they do not shift with daylight saving time (DST). Box labels the card Active time windows (UTC) for this reason.

Each window is one continuous span from a start day and time to an end day and time. A window from Monday 09:00 to Friday 17:00 therefore also covers the nights in between. To cover business hours only, add one window per day.

Convert your local hours to UTC before you enter them. For a store in New York that should be monitored from 07:00 to 20:00 on Monday:

Season in New York	Offset	Window to enter
Daylight time (March to November)	UTC−4	Monday 11:00 to Tuesday 00:00
Standard time (November to March)	UTC−5	Monday 12:00 to Tuesday 01:00

warning

Because the windows stay fixed in UTC, a window that matches your local business hours moves by one hour in local terms at every DST change. Update the windows twice a year, or enter one window that covers both seasons. In the example above, that is Monday 11:00 to Tuesday 01:00.

Other things to know about active time windows:

• A window that crosses midnight ends on the next day, for example Monday 22:00 to Tuesday 06:00. If you enter Monday 22:00 to Monday 06:00, the window wraps around the week and covers everything except Monday 06:00 to 22:00.
• Outside its windows a rule is not evaluated at all. No alerts are raised, updated, or resolved automatically until the next window opens.
• A rule is checked at its Check condition every interval, so the first check can come up to one interval after a window opens.
• A rule has one set of windows for all the devices it targets. If your devices span several timezones, create one rule per region and scope each rule by organization or by a tag condition.

Time-related conditions

• Incorrect time follows the incorrectTime flag described in Incorrect Time Detection. The clock check compares absolute instants, so a correct clock passes in any timezone. The timezone check compares the timezone the device reports with the timezone last set through Box or the REST API. It is skipped for devices whose timezone was never set through signageOS.
• Device is offline and applet command conditions use durations such as "more than 15 minutes" or "in the last hour". Durations are measured on the server clock and are independent of any timezone.

Alert dates, snoozing, and notifications

• Dates on the Alerts and Alert Rules pages are in UTC, for example Sat, Sep 26, 2026 2:00 AM (UTC). The one exception is the alerts panel on a device detail page, which uses the device's timezone like the rest of that page.
• When you snooze an alert, you pick the date and time in your browser's timezone. The Tomorrow shortcut means 09:00 tomorrow in your browser's timezone. The snooze is stored as an absolute instant and displayed back in UTC, so a snooze until 09:00 in Prague shows as 7:00 AM or 8:00 AM (UTC).
• Email notifications print the time in GMT, for example Tue, 21 Jun 2022 12:00:00 GMT. This is the moment signageOS generated the notification, not the moment the condition started on the device.
• In the REST API, alert dates such as createdAt, archivedAt, and snoozedUntil are ISO 8601 in UTC. Active time windows are sent as weekday names and HH:mm strings in UTC.
• Alert events exported through the Event Stream Distributor use UTC timestamps.

Device time and timezone

Each device keeps its own clock and timezone. You can set them in four ways:

• Box: device detail, Settings tab, Time card. See Time.
• Device Policy: the Timezone and NTP server item, which is the recommended way to manage a fleet. See Creating a new Device Policy.
• REST API: PUT /v1/device/{deviceUid}/time. See the REST API reference.
• JS API: sos.management.time.

On the device itself you can also use the OSD menu.

Timezones are IANA names such as Europe/Prague or America/New_York. Offsets such as +02:00 are not accepted. When you set a timezone together with an NTP server, the device keeps its clock synchronized on its own. Without an NTP server, signageOS sets the clock once and the device keeps time from its internal clock from then on.

A device reports its time when it connects and whenever its clock jumps or its timezone or NTP server changes. signageOS compares each report with the server time and raises the incorrectTime flag when they differ by more than 10 minutes.

tip

A clock that is far off also breaks the secure connection to signageOS, so the device appears offline. See the Troubleshooting Guide.

Device-specific behavior

Changing the time settings restarts or reboots most devices. The device confirms the change first and restarts about a second later, so the action shows as succeeded before the new time is in effect.

Platform	When you apply time settings	What to know	Guides
Samsung Tizen	Display reboots	Accepts only Samsung's limited timezone list. Always set an NTP server together with the timezone. Without one, only the display's hardware clock is set, the applet keeps the time Samsung derives from the display's IP address, and DST is switched off.	Tizen Timezones Limited List for NTP
Samsung SSSP 2 and 3	No restart	Only the clock can be set. Timezone and NTP server are not supported.
LG webOS	Application restarts	The timezone must be on LG's own list, otherwise the action fails with Timezone not found. webOS 1.x ignores the timezone and sets only the clock. webOS 2 and 3 can turn NTP on or off but use LG's default NTP servers. A custom NTP server needs webOS 4 or later.	LG webOS Device Provisioning, Network requirements
BrightSign	Player reboots	Use IANA names when you set the timezone through signageOS. Box shows the timezone only after it has been set through signageOS once. BrightSign's native zone codes are listed in the guide.	BrightSign supported Timezones
Android	No restart	Setting the time or timezone needs system-level permissions that depend on the Android version and on how the device is provisioned. DST rules come from the Android system, so they are as current as the device firmware.	Android Players Provisioning
Linux and Raspberry Pi	signageOS server on the device restarts, which can take up to 60 seconds	The device reports its timezone as an abbreviation such as CEST instead of the IANA name.
Windows	Kiosk browser restarts	IANA names are mapped to Windows time zones.
ChromeOS	Not applicable	Time settings are read-only in signageOS.

Gotchas

• Timezone names must match exactly. The incorrectTime timezone check compares names as text. If a device reports a different name for the same zone than the one you set, for example America/New_York after you set US/Eastern, the device stays flagged. Read currentTime.timezone from the device after the change and set exactly that name. Linux devices report an abbreviation, so the timezone part of the check fails on them once a timezone has been set through signageOS.
• Set the timezone in one way per device. The timezone check uses the value last set directly on the device in Box or the REST API. If a Device Policy later applies a different timezone, the device reports the policy timezone and is flagged as having incorrect time. Set the same timezone directly, or manage it by policy from the start.
• A policy timezone with the same current offset is not applied. The device compares the UTC offset of its current timezone with the offset of the policy timezone, not the names. A device on America/Phoenix that gets a policy with America/Denver in winter keeps America/Phoenix until the offsets diverge in March, and Box shows the policy item as not applied in the meantime. Set the timezone directly on such devices.
• DST rules are stored at the moment you apply the setting on Tizen and BrightSign. If the DST rules of a country change, apply the time settings again on those devices.
• NTP needs outbound UDP port 123. If the port is blocked, the device cannot synchronize and its clock drifts.
• Numeric time values in the REST API are epoch milliseconds. A value in seconds sets the device to January 1970. You can also send a wall-clock string without an offset, such as 2026-03-19T09:00:00, which is read in the timezone of the same request.
• GET /v1/device/{deviceUid}/time returns the history of time changes, not the current clock. The current clock is in currentTime on GET /v1/device/{deviceUid}.

Timers and scheduled actions

signageOS sends the times of these features to the device unchanged, and the device runs them against its own clock, even when it is offline:

Feature	Runs in	Notes
Timers	Device local time	Applies to both Native and Proprietary timers.
Scheduled power actions	Device local time
Content scheduled by your applet or playlist	Device local time, unless your content uses UTC explicitly	For SMIL, see Conditional playback.
Bulk action schedule	An absolute moment	You pick a date, time, and timezone in the wizard. The action starts at that one moment for all selected devices, wherever they are.

Because the device clock decides, a wrong clock or timezone shifts every timer and scheduled action on that device by the same error. Timers also follow the device through DST changes, so avoid scheduling in the hour that is skipped or repeated on a DST change day, usually between 01:00 and 03:00.

Box shows timer and scheduled power action times exactly as entered. Read them as the local time of that device, not as your own.

Time in Box

• UTC is the default. Unless one of the cases below applies, Box shows dates in UTC with a UTC label. This covers Alerts and Alert Rules and pages such as applets, bulk actions, policies, and organizations.
• Device data is shown in the device's timezone with the offset in the label, for example (UTC+02:00). This covers what a device reports: history, telemetry, uptime, screenshots, and logs. If a device has never reported its time, Box uses your browser's timezone. Past entries are shown with the device's current offset, so entries from before the last DST change appear one hour off. Other dates on a device page, such as when the device was created, notes, and custom script runs, are in UTC.
• Bulk actions show the scheduled time in the timezone you selected when you scheduled the action.
• License validity dates are UTC days. A license is valid from 00:00 UTC on its first day to the end of its last day in UTC.
• Your profile timezone (Account & Help, Profile, General, Timezone) is the default timezone when you schedule a bulk action, and it is used for the dates of your API tokens and multi-factor devices. It does not change other dates in Box.
• Locations have no timezone of their own. A location shows a clock only when all its devices report the same timezone.

Time in the REST API

• Timestamps in responses are ISO 8601 in UTC, for example 2026-05-05T12:00:00.000Z.
• The exception is currentTime on GET /v1/device/{deviceUid}, which returns the device clock with the device's offset together with timezone, ntpServer, and incorrectTime.
• Send dates in filters and request bodies, such as since, until, and snoozedUntil, as ISO 8601 with Z or an explicit offset. Do not send local times without an offset.
• Device logs carry two timestamps: recordedAt from the device clock and receivedAt from the server clock. Use receivedAt when you suspect the device clock is wrong.
• The device list CSV export uses UTC, with the device timezone in its own columns.

Best practices

1. Set a timezone and an NTP server on every device, preferably with a Device Policy, and allow outbound UDP port 123.
2. Use IANA timezone names, and check the platform lists for Tizen and LG webOS before you roll a timezone out.
3. Enter alert rule active time windows in UTC, review them at each DST change, and split rules by region when your fleet spans timezones.
4. Add an Incorrect time device alert, so that you hear about clock problems before they shift your timers.
5. Enter timers and scheduled power actions in the local time of the device.
6. In API integrations, send and store UTC, and convert to local time only for display.
7. Check your fleet regularly with GET /v1/device?filter[incorrectTime]=true.