StreamTest

XMLTV timestamps have no UTC offset

Timestamps without an explicit offset are ambiguous, and are the usual cause of a guide that appears shifted by whole hours.

What it means

XMLTV timestamps look like 20260101235900 +0100. Yours omit the trailing offset, leaving only the local-looking part.

Why it matters

Different clients guess differently: some assume UTC, some assume the device’s local timezone, some assume the server’s. The same guide then renders correctly for some viewers and shifted by hours for others — and it looks like a client bug rather than a data problem, so it goes unfixed for a long time.

How to fix it

  1. Append an explicit offset to every start and stop attribute, for example start="20260101235900 +0000".
  2. Use the offset in force at that moment, so entries either side of a daylight-saving change carry different offsets.

Check your own stream

The free EPG checker runs this check on every analysis and links each finding straight back here.

Open the EPG checker

Frequently asked questions

What does "XMLTV timestamps have no UTC offset" mean?
XMLTV timestamps look like 20260101235900 +0100. Yours omit the trailing offset, leaving only the local-looking part.
Why does it matter?
Different clients guess differently: some assume UTC, some assume the device’s local timezone, some assume the server’s. The same guide then renders correctly for some viewers and shifted by hours for others — and it looks like a client bug rather than a data problem, so it goes unfixed for a long time.
How do I fix it?
1. Append an explicit offset to every start and stop attribute, for example start="20260101235900 +0000". 2. Use the offset in force at that moment, so entries either side of a daylight-saving change carry different offsets.
How can I detect this automatically?
Paste your XMLTV programme guides URL into StreamTest's free EPG checker. It runs this check on every analysis, flags the finding, and links straight back to this page — no sign-up required.

Related Programme guides checks