A UTC offset describes how a timestamp’s wall-clock reading relates to UTC. It is not automatically an instruction to add that offset again in the player. Confusing the timestamp’s offset with a display adjustment is one reason a guide can end up several hours away from the intended programme.

Work with one dated example. An hour without a date and offset is an incomplete comparison, especially around midnight or a clock change. Keep the source timestamp, the expected local display and the player’s current zone setting as separate facts.

Does a screenshot prove panel access? — IPTV USA editorial illustration

One instant can have different clock readings

In a fictional schedule example, 18:00 at an offset of +0200 refers to the same instant as 16:00 at +0000. A player displaying that event in a zone whose offset is -0500 would show 11:00. The arithmetic illustrates offsets; it does not assign a permanent offset to a country or promise that a particular application performs the conversion correctly.

If the source already represents the correct instant, applying an extra two-hour manual shift can make it wrong. A global guide shift can also hide one channel’s bad metadata while damaging other channels that were already correct. Establish the source value before adjusting the whole guide.

Build a clear comparison

A named time zone and a numeric offset are not the same kind of information. A zone can have rules that change with date or local law. A numeric offset describes a particular relationship to UTC. Do not infer a country’s year-round clock policy from one guide example.

  1. Note the full programme date and source timestamp, including its offset.
  2. Record the device’s named time zone and whether automatic date/time is configured as intended.
  3. Compare one known programme in the player’s guide with the expected local instant.
  4. Check another channel to determine whether the discrepancy is global or source-specific.
  5. Keep any manual shift as a recorded, reversible change rather than an unexplained permanent fix.

Report the data, not only the size of the shift

“The guide is two hours late” leaves important questions unanswered. A stronger report says which programme, date, channel and local display were compared. If one source uses a different convention from another, that detail can explain why a universal adjustment fails.

Be careful when copying examples into public support. The timestamp and a fictionalized channel identifier can demonstrate a conversion issue without including the private playlist endpoint. Keep the exact shape of the date and offset so the example remains useful.

Once the discrepancy is corrected, revisit any earlier local overrides. A source update plus an old manual shift can recreate the problem in the opposite direction. The lasting improvement is a documented interpretation of the timestamps, not simply an offset that happened to look right on one evening.

Useful answers

Does +0200 mean the player should add two more hours?

It describes the timestamp’s relationship to UTC. Whether any display conversion is needed depends on the actual source and player settings.

Can one country always be assigned a single fixed offset?

No. Some countries have multiple zones or date-dependent rules. Use the relevant named zone and date.

Why can a manual shift fix one channel and break another?

The channels may use different source data or mappings. Compare more than one dated event before applying a global override.