Why a fixed number loses information
An offset such as UTC+10 is enough to describe the relationship between one local timestamp and UTC. It does not identify a city, seasonal rule or history. Several locations can share that offset on one date and diverge on another.
A named IANA location provides the rule context needed to convert dates. Australia/Sydney and Australia/Brisbane demonstrate the difference: sharing a clock relationship during part of the year does not make the locations interchangeable for every programme reminder.
Use each field for the question it answers
A guide source may provide an explicit offset with every timestamp. That can make each instant unambiguous, even without a location name. A recurring source-local schedule, however, needs the relevant rule context if future dates are to be generated accurately.
For a viewer, the practical question is whether the guide already supplies local times or expects the player to convert them. Applying a manual offset to already converted data can move a correct listing away from the programme’s actual start.
Civil rules can change independently of a programme
IANA updates reflect changes made by political bodies. A new rule can alter future conversions while a programme continues at the same source-local hour. Keep device data current, retain the intended date and avoid describing a historical offset as a permanent national clock.
Questions about this guide
Does UTC+10 identify Sydney uniquely?
No. An offset is shared by multiple locations and does not describe every date’s rules.
Is a named time zone the same thing as a country category?
No. One country can contain several locations, and a browsing category is not a clock rule.