The device time zone determines how local civil time is represented. A player’s guide-offset control is an additional adjustment to imported schedule data. Changing both to solve one discrepancy can create a second error that remains hidden until a later clock transition.
Start with a concrete programme and its source timestamp. A guide that is one hour wrong on one channel raises a different question from a device whose entire clock is wrong. Keep the scope of the observation narrow before applying a global shift.
Establish the reference time
Choose a dated event with an authoritative announced time and identify the relevant region. A short abbreviation alone can be ambiguous. Where possible, use the named time zone and the full date, because the offset from UTC can depend on seasonal or legal rules.
Then compare the device clock, imported timestamp and displayed grid position. A timestamp containing an explicit UTC offset supplies a different kind of evidence from a label that merely says “local time.” Do not strip an offset and silently substitute your own assumption.
Check the layers separately
If most listings are right and one edition is wrong, investigate that channel’s mapping and source time first. A global shift may make the one example look correct while moving every previously accurate channel.
- Confirm the device’s actual date, clock and named time-zone setting.
- Identify the source programme’s timestamp and any explicit offset.
- Record existing global and per-channel guide adjustments.
- Compare a known event before changing one relevant setting.
- Recheck unaffected channels and a second date after the correction.
Keep temporary corrections visible
A manual offset can be a useful documented workaround, but it should not be mistaken for a permanent time-zone rule. Record why it exists and review it after a source correction or seasonal change. An old workaround can apply twice when the upstream issue is fixed.
Do not assume every country changes clocks or follows the same transition date. Current regional rules should come from an authoritative time-zone source. This is especially relevant for viewers comparing events across borders, where a few weeks can have a different time difference from the rest of a season.
A helpful support note includes the event date, expected local time, actual displayed time, relevant named zone and existing offset controls. Keep account details out of the example. The desired outcome is a correct dated schedule in the viewer’s intended zone, not a particular numerical offset selected because it made one screenshot look right.
Useful answers
Should I change both device zone and guide shift together?
Check each layer first. Changing both can apply a correction twice.
Is a global shift a good first response to one wrong channel?
Usually inspect that channel’s mapping and source timestamp before disturbing correct listings.
Does the same UTC offset apply to every date in a named zone?
Not necessarily. Rules and seasonal changes can affect the offset.