Short answer: measure the error before you touch anything. If the guide is off by exactly one hour, it's almost always daylight saving or a feed that writes the wrong UTC offset, and it may fix itself within a week. If it's off by exactly three hours, you're probably watching a West Coast feed against an Eastern guide, which no time-shift setting should "fix". Only a steady whole-hour error that never changes is a job for the player's EPG time-shift setting. And apply that shift in one place only, because shifting in the source and the player is the most common reason people end up worse off than they started.
At a glance
Guide shows the wrong time
| First check | Device clock and timezone set to automatic |
| Off by 1 hour | DST or a bad offset in the guide data |
| Off by 3 hours | East/West feed mix-up, not a clock fault |
| Autumn 2026 trap | Oct 25 to Nov 1: Europe and US out of step |
| Golden rule | Shift in one place, never two |
Measure the error first
Most guides on this tell you to try offsets until the guide looks right. That works, sort of, but it hides the cause, and the cause decides whether your fix will still be right next month.
So pick a channel where you can see the truth. A news channel at the top of the hour is ideal: the anchor says "it's nine o'clock" and a new programme starts. Note what the guide says is on, and when it thinks that programme started. The gap between the two is your number.
| Size of the error | Most likely cause | What to do |
|---|---|---|
| Exactly 1 hour, started recently | Daylight saving changeover handled badly | Wait out the gap week, then re-check |
| Exactly 1 hour, all year | Guide data carries the wrong UTC offset | Player time shift of +1 or -1 |
| Exactly 3 hours (US) | Pacific feed matched to an Eastern guide, or the reverse | Use the right feed's guide entry |
| Whole hours, several of them | Guide in UTC with no offset, or device timezone wrong | Fix device timezone, then shift if still needed |
| 30 or 45 minutes | Half-hour zone (India, Newfoundland, Nepal) rounded | Player must support fractional shift |
| A few minutes | Not a timezone issue: schedule overrun or stale data | Refresh the guide; live events always overrun |
| Different on different channels | Channels pulled from different guide sources | Per-channel shift, or ask the provider |
That last row matters. If one channel is right and its neighbour is an hour out, no global setting can fix both. You need a per-channel shift, or a better guide source for the broken one.
Where guide times actually come from
The programme guide in almost every IPTV player is an XMLTV file. Each programme in it has a start and stop time written like this:
<programme start="20261004210000 -0400" stop="20261004220000 -0400" channel="WABC.us">
That reads as 9pm on October 4, 2026, four hours behind UTC, which is US Eastern Daylight Time. Your player converts it to your device's local time. If the file is honest about its offset and your device knows where it is, the guide is right automatically. No shifting required.
Things go wrong when that last part of the timestamp lies. A guide generator might write +0000 on times that are actually local, so 9pm Eastern gets treated as 9pm UTC and shows up four hours early. That exact bug was reported in late 2025 against Dispatcharr, a popular self-hosted guide tool, where times written as +0100 came out as the same clock time with +0000 attached. One hour out, for every European channel, until it was patched.
You can check this yourself. Paste the EPG URL into a browser (or open the downloaded .xml file in a text editor), search for a channel you know, and look at the offset on a programme you can verify. If 9pm news is written as 210000 +0000, the source is wrong and you've found your answer. What's inside an M3U playlist covers the other half of this pairing.
Rule out your own clock
Boring, but it catches a lot of people. The player converts guide times using the device's timezone, not your router's and not your TV's. A streaming stick set to the wrong zone shows a perfectly good guide wrongly.
- Fire TV: Settings > Preferences > Time Zone. On older Fire OS builds it's under Settings > Device & Software > Date & Time.
- Google TV / Android TV: Settings > System > Date & time. Turn on automatic date and time and automatic time zone.
- Apple TV: Settings > General > Time Zone, with "Set Automatically" on.
- Samsung (Tizen): Settings > General > System Manager > Time > Clock, then Clock Mode: Auto.
- LG (webOS): Settings > General > System > Time & Date, with "Set Automatically" on.
Menu names drift between firmware versions, so if yours differs slightly, look for "Date & Time" under System. After changing it, force-close the player and reopen it. Many players only read the timezone at launch.
One extra catch: some devices set up with a VPN app running pick a timezone from the VPN's exit location. If your clock jumped after installing one, that's why. Whether you need a VPN for IPTV at all is a separate question, and usually the answer is no.
The daylight saving gap weeks
Here's the one nobody explains properly. Europe and the US don't change their clocks on the same day, and for a week or more each spring and autumn, a guide built in one region can drift against the other.
| 2026 date | What changes | Effect on a mixed guide |
|---|---|---|
| Sunday, March 8 | US clocks go forward | European-built guides showing US channels can run 1h out |
| Sunday, March 29 | EU and UK clocks go forward | Back in step |
| Sunday, October 25 | EU and UK clocks go back | Out of step again |
| Sunday, November 1 | US clocks go back | Back in step |
A properly written XMLTV file handles this fine, because each programme carries its own offset. The trouble comes from guide generators that apply one fixed offset to a whole week of data, or from a time shift you set manually in the summer. A +1 that was right in August is wrong after November 1.
So if your guide went one hour wrong on a Sunday morning in late October or early November, don't touch anything for a week. If it's still wrong after November 1, then fix it. And if you did set a manual shift earlier in the year, that's the first thing to undo. Arizona and Hawaii don't observe daylight saving, which makes them a permanent edge case for guides built around US Eastern time.
Three hours out: East and West feeds
US cable channels run separate East and West feeds. HBO, AMC, Food Network and plenty more broadcast the same schedule three hours apart. The guide data for the East feed is right for the East feed.
So if your playlist entry is actually the Pacific feed but its guide ID points at the Eastern listings, the guide says "8pm movie starting" while you're watching the end of something else. People "fix" this with a -3 shift and then wonder why every other channel broke.
Don't shift. Check whether your service has separate entries for each feed and match each to its own guide channel. This is a guide ID problem, not a clock problem, and our guide on diagnosing EPG faults by symptom walks through the wider set of mismatches. Licensed services like YouTube TV and Sling handle feeds for you based on your location, which is one of the quieter advantages of their own apps.
Setting the shift, player by player
Only do this once you've confirmed a steady error that isn't DST and isn't a feed mix-up.
TiviMate. Open Settings > EPG, then select the guide source. Recent versions offer a time-shift value per source, in hours. Because it's per source, you can shift one bad guide without touching a good one, which is exactly what you want. Then use "Update EPG" so the grid redraws. Our TiviMate walkthrough covers where the other options live.
Kodi with IPTV Simple Client. Go to Add-ons > My add-ons > PVR clients > PVR IPTV Simple Client > Configure > EPG. "EPG time shift" accepts -12 to +14 hours. There's a separate toggle to apply that shift to all channels, overriding any per-channel value. If it's off, the global shift and any per-channel tvg-shift in the playlist are added together. That's useful, and also the root of the double-shift problem below. The add-on's EPG settings also include a case-insensitive matching option, which matters if some channels have no guide at all.
The playlist itself. An M3U can carry tvg-shift="1" in the #EXTINF line for a single channel, or in the #EXTM3U header for all of them. Not every player honours it. Kodi does; many others ignore it silently.
IPTV Smarters and similar. Look under Settings for an EPG time shift or "EPG timeline" option. Labels vary by version and by which rebrand of the app you have.
Plex and Channels DVR. Both rely on your server's timezone and the offsets in the XMLTV file. There isn't a simple shift slider in Plex, so a bad offset has to be fixed at the source, or by running the file through a guide tool that rewrites it.
Half-hour zones are the awkward case. India is UTC+5:30, Newfoundland is UTC-3:30 (UTC-2:30 in summer). Players that accept only whole hours can't correct a guide that's out by 30 minutes. If you watch Indian channels from the US and the guide is consistently half an hour off, the realistic fix is a correctly-offset source. Indian channels in the USA covers the licensed services, whose own apps handle this for you.
The double-shift trap
This is the one that has people insisting "the setting doesn't work".
A shift can live in up to four places: the guide generator, the playlist's tvg-shift, the player's per-source shift, and the player's global shift. Several of them add together. Set +1 in two of them and you're now two hours out, in the other direction from where you started.
The clean way out:
- Set every shift you know about back to zero.
- Confirm the device timezone is right.
- Refresh the guide and measure again against a channel you can verify.
- Apply the correction in exactly one place, the narrowest one that fixes it. Per-channel if one channel is wrong, per-source if one source is wrong, global only if everything is.
- Write down what you set and why. In March you'll want to know.
Catch-up and recordings
A guide that's an hour out does more damage than a confusing grid. Catch-up requests are built from guide times, so pressing play on yesterday's 9pm match asks the server for the wrong hour of archive. Recordings scheduled from the grid start late and cut off the end.
Kodi's IPTV Simple Client has a separate catchup-correction attribute for exactly this, because a catch-up server can sit in a different timezone from the guide. If live guide times look right but archive playback starts an hour off, that's the setting to look at, not the main shift. How catch-up archives work explains why.
For anything you really care about recording, pad the start and end by a few minutes regardless. Live sport overruns, and no guide predicts that.
And if the whole thing is a licensed service's own app showing wrong times, the shift isn't yours to fix. Report it to them with the channel, the time you saw, and the time the guide claimed. That's a five-minute fix on their side.
Quick answers
Why is my IPTV guide exactly one hour off? Usually a daylight saving changeover or a guide file carrying the wrong UTC offset. If it started on a late-October or early-November Sunday, wait a week before changing anything.
Why is my guide three hours wrong on some channels? On US channels that's almost always a West Coast feed matched to East Coast listings. Match the feed to its own guide entry instead of shifting the time.
Should I change my device timezone to make the guide line up? No. Set the device to your real timezone, automatically, and correct the guide in the player. Changing the device clock breaks other apps.
I set a time shift and it got worse. Why? The shift is probably being applied twice, once in the playlist or source and once in the player. Zero every shift, measure, then apply one correction in one place.
Can I fix a guide that's 30 minutes out? Only if your player accepts fractional shifts. Many accept whole hours only, so a correctly-offset guide source is the real fix.
Does a wrong guide time affect catch-up? Yes. Catch-up and scheduled recordings use guide times, so they'll start in the wrong place. Kodi has a separate catch-up correction for this.
How do I check the guide file myself? Open the XMLTV URL or file, find a programme you can verify, and read the offset after the start time. A local time with +0000 attached means the source is wrong.
Menu names vary between app and firmware versions. Daylight saving dates are for 2026. Checked September 2026.