Why is my guide correct in winter but an hour off in summer?

This is the signature of a hardcoded UTC offset that does not account for daylight saving time. The guide generator wrote a fixed offset that happens to be correct for standard time but wrong by one hour once DST shifts the true local offset.

What does it mean if an XMLTV timestamp has no +ZZZZ offset at all?

The spec says an omitted offset should be read as UTC, but not all players follow that rule consistently — some substitute the device's local timezone instead. Whether this causes a visible shift depends entirely on how far the device's local timezone is from actual UTC.

Is a 10+ hour guide shift the same kind of bug as a 1-hour shift?

No. A shift of one or two hours that changes with the season points to a DST-unaware offset. A shift of many hours, constant year-round, points to a sign error or the wrong offset entirely, such as a file authored for one timezone being served to viewers in a very different one.

Can changing my device timezone fix a shifted EPG?

Only if the XMLTV file omits offsets and the player falls back to system-local time — in that specific case, matching the device timezone to the offset the generator assumed can mask the bug. If the file carries an explicit and correct offset, changing the device timezone will not fix a broken guide and may break the live-TV clock display instead.

Does a shifted EPG mean the stream itself is also wrong?

No, these are independent. The EPG timestamps only affect what the guide displays for programme start and stop times; they have no bearing on the live stream's actual video/audio delivery, which is a separate pipeline entirely.

EPG shifted by hours: fixing XMLTV timezone offsets

An EPG shifted by a fixed number of hours almost always means the timezone offset written in the XMLTV timestamps does not match what the player assumes when it converts to local time. This is a display/interpretation problem, not a data corruption problem — the underlying schedule is usually correct, it is just being read against the wrong timezone.

XMLTV timestamps carry their own offset in every start and stop attribute, in the form YYYYMMDDHHMMSS +ZZZZ. When the guide is consistently off by exactly one or several whole hours, the fix is almost always in that offset field or in how the player is configured to interpret it, and checking which one is wrong takes reading a handful of raw timestamps rather than guessing.

This guide explains the XMLTV timestamp format, the specific ways an offset goes wrong (wrong sign, stale DST offset, offset stripped entirely), and how to distinguish a source-file problem from a player-side timezone setting problem.

The XMLTV timestamp format and what the offset means

A programme element carries start and stop attributes like start="20260916190000 +0200" stop="20260916200000 +0200". The digits are year, month, day, hour, minute, second in that fixed order, and the trailing +ZZZZ or -ZZZZ is the UTC offset the timestamp was written in — it is not the viewer's timezone, it is whatever offset the guide provider used when generating the file. A correct XMLTV consumer converts this to UTC internally (subtracting the offset) and then re-renders in the device's local timezone for display.

A shift of exactly one hour across every programme, all day, every day, points to a fixed offset error rather than anything time-dependent — the whole schedule was generated against one wrong constant.

Missing or stripped offsets

If a timestamp has no offset at all — just start="20260916190000" — the XMLTV spec technically allows this and says an omitted offset should be treated as UTC, but not every parser follows that rule; some assume the local system timezone instead. When a guide provider strips offsets (often because their generator was authored somewhere that always used UTC without being explicit about it) and the player instead assumes system-local time, the entire guide shifts by exactly the difference between UTC and that system's local offset — for example a 2-hour shift for a device set to UTC+2.

Wrong-sign and stale-DST offsets

A generator that hardcodes an offset rather than computing it for each date will produce a guide that is correct for half the year and off by exactly one hour for the other half, once daylight saving time changes. A file with +0100 stamped on every entry through a period when the true local offset is +0200 (summer time in effect) shows every programme an hour early for that whole season, then self-corrects when the file is regenerated for winter — that pattern (right in winter, wrong by one hour in summer, or vice versa) is the signature of a hardcoded rather than DST-aware offset.

A sign error (writing -0500 instead of +0500) produces a much larger and more obviously wrong shift — ten hours off rather than one or two — and is easy to distinguish from a DST issue precisely because the size of the error does not match any real timezone's DST delta.

Player-side timezone settings compounding the problem

Some players let the user set an explicit "EPG timezone" or "guide offset" independent of the device system clock, intended to correct known-bad feeds. If this setting is left over from a previous, differently-broken guide source, it will now apply an unwanted correction on top of an otherwise-correct file, producing a shift that looks like a source problem but is actually a leftover player setting. The tell is that the shift changes (or disappears) when the same XMLTV file is loaded in a different player or after the guide-offset setting is reset to zero.

How to isolate the source of the shift

Open the raw XMLTV file and read the offset on a programme you know is currently airing or about to air. Convert that timestamp to UTC by hand (subtract the offset), then convert to your real local time. If that hand calculation matches the real broadcast time, the file is correct and the fault is in the player's interpretation or a leftover manual offset setting. If the hand calculation itself does not match reality, the file's offset is wrong at the source.

Comparing two programmes on the same channel several months apart (one inside DST, one outside) is the fastest way to tell a hardcoded-offset bug from a sign error: a DST bug shows a correct offset in one season and a one-hour error in the other, while a sign error is wrong by a large, constant amount in both.

Step by step

Pick one currently-airing programme and read its raw start attribute, including the +ZZZZ or -ZZZZ offset.
Convert that timestamp to UTC by subtracting the offset, then convert to your actual local time.
Compare the result to the real broadcast time for that programme from the broadcaster's own schedule.
If the file's implied time is correct but the app displays it wrong, check for a manual EPG-timezone or guide-offset override in the app settings.
If the file's implied time is itself wrong, compare a summer-dated and winter-dated programme on the same channel to distinguish a hardcoded DST offset from a flat sign error.
Reload the file in a second player with no manual overrides to confirm whether the shift travels with the file or was player-specific.

Run it yourself

Free, no sign-up, and every finding links to an explainer.

EPG checker →EPG matcher →

Frequently asked questions

Why is my guide correct in winter but an hour off in summer?: This is the signature of a hardcoded UTC offset that does not account for daylight saving time. The guide generator wrote a fixed offset that happens to be correct for standard time but wrong by one hour once DST shifts the true local offset.
What does it mean if an XMLTV timestamp has no +ZZZZ offset at all?: The spec says an omitted offset should be read as UTC, but not all players follow that rule consistently — some substitute the device's local timezone instead. Whether this causes a visible shift depends entirely on how far the device's local timezone is from actual UTC.
Is a 10+ hour guide shift the same kind of bug as a 1-hour shift?: No. A shift of one or two hours that changes with the season points to a DST-unaware offset. A shift of many hours, constant year-round, points to a sign error or the wrong offset entirely, such as a file authored for one timezone being served to viewers in a very different one.
Can changing my device timezone fix a shifted EPG?: Only if the XMLTV file omits offsets and the player falls back to system-local time — in that specific case, matching the device timezone to the offset the generator assumed can mask the bug. If the file carries an explicit and correct offset, changing the device timezone will not fix a broken guide and may break the live-TV clock display instead.
Does a shifted EPG mean the stream itself is also wrong?: No, these are independent. The EPG timestamps only affect what the guide displays for programme start and stop times; they have no bearing on the live stream's actual video/audio delivery, which is a separate pipeline entirely.