Google日历ICAL URL订阅时间异常，但ICS文件导入正常问题排查

问题原因 #

• 时间格式兼容性问题：谷歌日历通过URL订阅ICAL时，对时间字段的解析规则比导入ICS文件更严格。如果源ICAL数据里的DTSTART、DTEND字段缺少标准时区标识（TZID），或者使用了非IANA标准的时区名称，谷歌会默认按UTC时区解析，转换到本地时区后可能出现固定偏移，最终显示为12:00-12:30。而导入ICS文件时，谷歌会采用更宽松的解析逻辑，自动适配本地时区。
• 源ICAL数据输出错误：生成订阅链接的服务可能存在bug，输出ICAL数据时错误地将所有事件的时间替换为12:00-12:30，但导出ICS文件时使用了正确的时间数据。直接访问订阅链接查看返回的ICS内容，对比导出的文件就能验证这一点。
• 谷歌日历缓存残留：订阅URL后，谷歌会缓存ICAL数据。如果之前的错误数据被缓存，即使源数据已修正，仍会显示旧的错误时间。而导入ICS是直接读取最新文件，不受缓存影响。

解决方法 #

• 修正ICAL时间格式：确保源ICAL文件的每个事件都包含标准时区信息，示例如下：

  DTSTART;TZID=Asia/Shanghai:20240520140000
  DTEND;TZID=Asia/Shanghai:20240520150000
  

  必须使用IANA标准时区标识符（如Asia/Shanghai），避免无时区的裸时间格式。如果使用自定义时区，需在ICAL文件中完整定义VTIMEZONE块。
• 排查源服务输出逻辑：如果ICAL链接由第三方服务生成，检查其输出订阅链接和导出ICS文件的逻辑是否一致。若存在差异，修复服务的ICAL生成代码，确保订阅链接返回的时间数据正确。
• 刷新谷歌日历订阅缓存：进入订阅日历的设置页面，找到「刷新」选项手动触发数据更新；若没有该选项，先删除订阅，等待15分钟左右再重新订阅，避免缓存残留影响。
• 校验ICAL数据合法性：使用本地ICAL解析工具检查源数据是否符合RFC 5545标准，确保时间字段无语法错误，时区定义完整。

内容的提问来源于stack exchange，提问作者Antony