如果您的 IPTV 频道 EPG（电子节目单）里节目都对，时间却不对——每档节目都比实际播出时间整体偏差一两个小时——那么您遇到的正是现实中最顽固、最常见的 XMLTV 问题之一。修复通常只需改动一行 URL，而诊断该往哪个方向平移，大约只要五分钟。
本指南会带您弄清这个问题的真正根源、如何算出所需的偏移量，以及如何应用它。实际的平移由本站的 EPG 时区平移工具完成；这篇文章讲的是如何正确使用它。
同一档节目，两个时钟：EPG 比墙上时钟慢两小时，直到平移工具把它重新对齐。
为什么 XMLTV 会出现时区问题
XMLTV 是一个已有 25 年历史的格式。每档节目都带有形如下面的 start 和 stop 属性：
<programme start="20260507180000 +0000" stop="20260507190000 +0000" channel="bbc1">
前 14 位数字是墙上时钟时间；结尾的 +0000 是这个墙上时钟所处的时区偏移。因此 20260507180000 +0000 的意思是“2026 年 5 月 7 日 18:00 UTC”。播放器读取两者，换算到您本地的时区——如果您在欧洲中部时间（CET），就会显示“20:00”。
前提是这份 XMLTV 文件内部自洽。但 XMLTV 是由一长串程序接力生成的：
- 广播方原始的节目编排系统，用的是他们当地的时区。
- 区域聚合方，可能会把时间转换成某个区域时区。
- IPTV 服务商的抓取程序，多半又处理了一遍。
- 服务商的 XMLTV 导出器，不管数字到底是不是 UTC，一律在末尾拍上一个
+0000。
这条链上的任何一环都可能引入时区错误，而这个格式没有任何校验机制。输出的文件看起来格式规范，播放器无从察觉里面的数字与声明的偏移并不匹配。结果就是一份理直气壮地整体错上若干小时的节目单。
第二类问题是 XMLTV 文件干脆完全省略了偏移量：
<programme start="20260507180000" stop="20260507190000" channel="bbc1">
没有偏移量，播放器只能靠猜。大多数播放器假定“数字就是您的本地时间”，也有一些假定是 UTC。如果服务商的本意是 UTC 而您的播放器按本地时间理解，那么每档节目都会偏差您本地时区的偏移量。
这两种情况下，底层数据本身都是对的——只需要把数字统一加上或减去一个值，让它们落到正确的位置。
算出您需要的偏移量
修复方法就是“给 XMLTV 文件里的每个时间戳加上 N 小时”。要确定 N 的值：
第 1 步：挑一个您确切知道此刻在播什么的频道
打开播放器，找一个正在直播、且您确实知道在播什么的频道——18:00 的本地新闻、整点的 BBC News、大台的黄金时段节目。关键是要有一个已知的锚点：“这个频道此时此刻正在播 X，我表上的墙上时钟正是这个时间”。
第 2 步：看看 EPG 怎么说
在播放器里查看同一频道的“正在播放”条目，记下它声称的开始时间。如果它说节目 16:00 就开始了，而实际是 18:00 开播，那么 EPG 慢了两小时——您需要给每个时间戳加 2。
如果 EPG 显示节目“两小时后开始”，但它此刻明明正在播出，那么 EPG 快了两小时——您需要减 2。
第 3 步：在多个频道上确认偏移量一致
再挑第二、第三个频道，验证偏移量是否一致。如果频道 A 偏了 +2 而频道 B 偏了 -3，那您遇到的就不是时区问题，而是各频道数据本身不一致，固定平移无法同时修好两者。（多频道不一致的情况很少见，通常意味着服务商合并了多个来源的数据却没有统一时区——那种情况唯一的办法是请服务商清理数据。）
95% 以上的情况下，所有频道的偏移量是一致的，取值通常是 ±1、±2、±3；对于与服务商源数据所在时区相距很远的用户，有时是 ±5 或 ±8。
应用平移
知道偏移量之后，平移工具会给您一个新的 URL：它转发您服务商的 XMLTV，并把每个时间戳精确平移相应的量。把播放器里的 EPG URL 换成这个新地址，节目单的时间就对齐了。
两点实用说明：
- 平移工具是一个代理，而不是一次性转换。您的播放器每隔几小时就会刷新 EPG。每次刷新都会经由平移工具重新拉取服务商的 XMLTV，并重新应用偏移。我们这边不做任何缓存；上游的权威数据依然说了算，只是时间被平移了而已。
- 您的凭据会出现在 URL 中。大多数 IPTV 服务商通过形如
http://server/xmltv.php?username=...&password=...的 URL 提供 XMLTV。平移工具只在请求时读取这些凭据用于拉取上游——不记录、不缓存、也不索引。在写入我们的访问日志之前，查询字符串也会被剥除。
平移工具解决不了的问题
有几类相邻的问题看起来像时区错误，其实不是：
节目时而准、时而不准
如果 EPG 有时对、有时不对，那就不是时区问题。可能的原因有：
- 服务商的数据过期了。较旧的节目条目按较慢的节奏刷新，较新的条目来自更新鲜的数据源。两路数据可能处于不同的时区，却混在同一份 XMLTV 里。没有服务商配合很难修复。
- 夏令时（DST）。如果您所在的时区实行夏令时而服务商的 XMLTV 不实行（或者反过来），偏移量每年会变动两次、每次一小时。固定偏移的平移只在您完成校准的那半年内有效。
专门针对夏令时问题，您可以保留两个不同偏移量的 URL——上下半年各一个——每年切换两次播放器的 EPG 来源。麻烦，但管用。
节目单是空的，不是时间不对
“暂无信息”/空白节目单是另一个问题。请见如何解决 EPG 无法加载——那种情况的原因通常是播放列表与 XMLTV 之间的 tvg-id 不匹配，不是时区。
个别频道不对，但大多数是对的
如果其他一切正常、只有一两个频道时间错位，那是这些频道的源数据在服务商那端就是错的。固定偏移的平移会为了修好错的频道而弄坏对的频道。要么请服务商修数据，要么接受这几个频道的时间只能是近似值。
为什么我们不自动检测偏移量
时区调整器把偏移量作为显式参数，而不是自己去猜。理论上我们可以抓取文件、把节目开始时间与“现在”对比、然后猜一个值。我们不这么做，因为：
- “正确答案”取决于您以哪个频道为锚点。不同频道可能互相矛盾。
- 猜错比开口问更糟。如果我们悄悄按错误的量平移，您得到的是一份按另一个值持续错下去的节目单，还得浪费时间排查。
- 用户掌握着上下文。用户知道“18:00 的 BBC One 新闻现在在节目单里显示成 16:00”。工具一键就能应用这个知识；靠网络观测推导它并不可靠。
修复之后
用上面的第 1 步再验证一遍：已知频道、当前节目、核对播放器的正在播出时间。现在它应该与墙上时钟一致。如果一致，修复就是永久性的——播放器会持续通过调整器 URL 刷新，偏移量一直生效。
如果还有别的问题（没被平移的频道、不匹配的 ID、覆盖缺口），那些是独立的问题，下一步是求助 EPG 校验器。校验器解析 XMLTV 文件并报告与时间无关的结构性问题——当您想知道“文件本身是否规范”而不是“时间对不对”时很有用。
IPTV 侧的其余问题，Xtream 凭据检查器和 M3U 播放列表测试器覆盖播放列表和凭据的边角情况。加上时区调整器，这四个工具能搞定人们原本只能在论坛里摸黑折腾的大部分排查。