XMLTV / worked schedule interpretation · Primary-source explanation; no UK IPTV implementation or account test. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Keep all three parts of the timestamp
A support note containing only00:15 leaves out information needed to identify a programme instant. Retain the date and the source’s offset before comparing it with another schedule. XMLTV’s timestamp convention includes both clock information and timezone context. Do not use the programme’s production country as a substitute for the actual supplied timestamp.
Work through a precise hypothetical value
Take5November2026 at00:15 with offset+05:30. Subtracting five hours and thirty minutes gives4November2026 at18:45 UTC. The date has moved backwards as well as the clock. The same instant described at offset zero would use the previous day. This is original offset arithmetic, not a claim about a particular country’s current clock policy or any actual broadcaster listing.
Compare like with like
If one consumer shows the source-local date and another shows UTC, the two date labels can differ while referring to the same instant. Normalize the complete values before declaring one wrong. Conversely, matching19:00 on two screens does not prove the same instant if their offsets or dates differ. Keep the intended display timezone explicit in the example.
Report a complete reproducible case
Provide the original sanitized timestamp, expected display timezone and actual date/time shown. Check the actual broadcaster edition and current listing separately. Avoid fixing the hour while leaving the day attached to its original value. This worked example establishes no UK IPTV guide offset, feed contents or performed player conversion test.