Time Zones and Schedules

Two different pieces of time information hang off the inventory model, at two different levels.

A time zone belongs to the screen, and says what local time means at that location. A schedule belongs to the face, and says which hours of which days it operates.

This page is for every employee role — both values are read-only in the interface — who need to know how the values are derived and where they are consumed.

The screen’s time zone

The platform derives the time zone from the screen’s coordinates and stores the resulting IANA identifier — Europe/Belgrade, Asia/Almaty and so on — on the screen. It is worked out when a screen is first created, and again when a synchronization run brings different coordinates. The value cannot be set directly.

Where the time zone matters

Report timestamps

Every row of the requests report is written in the time zone of the face’s screen, formatted with its offset, and falls back to UTC where the screen has none. A report covering screens in several time zones therefore shows each row in its own local time.

Time-dependent evaluation during a request

When an ad request arrives, the instant it carries is converted into the screen’s local time before anything that varies by time of day is resolved. Settings expressed as a day of the week and a time of day are matched against the screen’s local clock.

Playout timestamps

Where a content management integration reports the time an ad played without an offset, the value is interpreted in the screen’s time zone.

What demand partners are told

The time zone is published with the screen in the catalog CityScreen Context exposes to demand partners, and in the catalog exposed for automated guaranteed booking, so partners can reason about local time themselves.

The face’s schedule

A schedule is a set of operating windows, one or more per day of the week, each expressed as a start and an end offset from local midnight. Two faces on the same screen can have different schedules.

The schedule comes from the source, and is replaced wholesale on every synchronization run that finds it different. A face’s operating hours are changed in the content management system.

A face’s detail page shows the schedule as a week grid, read-only. Beside it are two flags the source supplies — "allow by days" and "allow by hours" — which CityScreen Context stores and passes on to demand partners as it received them, without acting on them itself.

Where the schedule matters

The schedule is published, per face, in the catalog CityScreen Context exposes to demand partners — grouped by day of the week, each day carrying its operating periods as second offsets from local midnight.

CityScreen Context publishes the operating hours and does not filter the auction by them; the content management system decides when to ask, and it asks when the face is running.

The schedule describes when a face runs. What a face may be sold for, and to whom, is decided by the price lists covering it — see RTB price lists.

Related

  • Inventory — why the time zone sits on the screen and the schedule on the face.

  • Synchronization — the run that replaces the schedule.

  • Reporting — what the timestamps in a report are counting.