使用ical.net时重复事件丢失自动时区转换问题

我之前用ical.net开发日历邀请功能时，也碰到过一模一样的重复事件时区失效问题！核心原因几乎都是重复规则（RRULE）或事件时间没有正确关联时区元数据，给你几个具体的排查和修复步骤：

1. 强制给事件起止时间绑定明确时区 #

非重复事件正常，大概率是你默认给Start/End用了带时区的CalDateTime，但添加重复规则后，可能不小心让时间丢失了时区标记。一定要确保：

• 用CalDateTime构造函数时直接传入时区对象
• 显式设置IsTimeZoneSpecified = true（有些场景下ical.net不会自动推断）

示例代码：

// 先获取对应时区（-7时区通常是太平洋夏令时，用系统时区ID更靠谱）
var targetTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");

// 创建带时区的事件时间
var eventStart = new CalDateTime(new DateTime(2024, 5, 20, 16, 0, 0), targetTimeZone) 
{ 
    IsTimeZoneSpecified = true 
};
var eventEnd = new CalDateTime(new DateTime(2024, 5, 20, 19, 0, 0), targetTimeZone) 
{ 
    IsTimeZoneSpecified = true 
};

// 绑定到事件
var calendarEvent = new Event
{
    Summary = "每周同步会议",
    Start = eventStart,
    End = eventEnd,
    // 其他配置...
};

2. 确保重复规则的时间也关联时区 #

如果你的RRULE用到了Until参数（比如重复到某一天），绝对不能直接传本地DateTime，必须用带时区的CalDateTime，否则RRULE会脱离事件的时区上下文：

var recurrenceRule = new RecurrenceRule(FrequencyType.Weekly, 1)
{
    Count = 4, // 重复4次
    // 如果用Until，一定要带时区
    // Until = new CalDateTime(new DateTime(2024, 6, 17, 16, 0, 0), targetTimeZone)
};
calendarEvent.RecurrenceRules.Add(recurrenceRule);

3. 验证生成的ICS内容（关键排查步骤） #

把生成的ICS文本打印出来，对比非重复和重复事件的差异：

• 正常的带时区事件应该有类似 DTSTART;TZID=Pacific Standard Time:20240520T160000 的行
• 如果重复事件的DTSTART没有TZID标记，或者RRULE里的时间是UTC格式（带Z后缀），那客户端肯定不会自动转换时区

4. 避免混用本地时间/UTC时间 #

整个事件配置过程中，要统一用带时区的CalDateTime，不要一会儿传UTC时间，一会儿传本地时间。ical.net对时间类型的一致性要求很高，混用很容易导致时区信息丢失。

如果按照上面的步骤调整后还是有问题，把生成的ICS内容片段贴出来，应该能快速定位到具体的配置疏漏~

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