Parsing iCal-由Thunderbird生成的奇怪事件 我正在用C++编写一个ICA解析器。在本文中，我注意到几个事件，都是由Thunderbird生成的，我的解析器无法正确解析

以下是其中一个事件的示例：

BEGIN:VEVENT
CREATED:20170111T221139Z
LAST-MODIFIED:20170111T221145Z
DTSTAMP:20170111T221145Z
UID:882f4c15-03e9-451c-bf4f-b3422ed8ef54
RDATE;VALUE=DATE-TIME:20170111T163000Z
DTSTART;TZID=Europe/Berlin:20170111T173000
DTEND;TZID=Europe/Berlin:20170111T173000
X-MOZ-FAKED-MASTER:1
X-MOZ-GENERATION:1
END:VEVENT
BEGIN:VEVENT
CREATED:20170106T215137Z
LAST-MODIFIED:20170111T221145Z
DTSTAMP:20170111T221145Z
UID:882f4c15-03e9-451c-bf4f-b3422ed8ef54
SUMMARY:Obst
RECURRENCE-ID;TZID=Europe/Berlin:20170111T173000
DTSTART;TZID=Europe/Berlin:20170111T194500
DTEND;TZID=Europe/Berlin:20170111T201500
SEQUENCE:7
TRANSP:OPAQUE
X-MOZ-GENERATION:12
END:VEVENT

我注意到这次活动的几个特点：

主事件不包含摘要，只有链接的异常包含摘要。 开始日期和结束日期相等。 主事件不包含任何定期规则RRULE，但包含定期日期RDATE。 主事件中的重复日期位于事件开始日期和时间前30分钟。 我尝试在谷歌日历和Outlook中导入它。在谷歌日历中，事件显示在正确的日期和时间，警报设置为事件发生前30分钟。使用Outlook 2013，我只能部分导入事件，下面的屏幕截图上会显示错误消息。我想只导入了第二个VEVENT，因为第一个VEVENT不包含标题

我不知道这个事件是如何建立的。为此，我有几个问题：

此事件是否正确生成，或者可能是Thunderbird日历中的错误？ RDATE模式可能不存在RRULE？这有意义吗？ RDATE模式中的日期是否应被视为警报，而不是最终复发的事件？ 在这种情况下，主事件和他的异常之间的关系是什么，因为主事件不包含RDATE模式之外的任何重复规则，而RDATE模式似乎不是真正的重复规则？ 未记录的X-MOZ-FAKED-MASTER属性可能是什么意思？这与这个奇怪事件的发生方式有关吗？

---

从标准的角度来看，只使用RDATE而不使用RRULE可以完美地表示重复事件。一些遗留客户端（如Lotus Notes）总是将重复规则转换为一系列RDATE。看看你是怎么计算的 实际上，大多数最近的客户端不能很好地处理包含RDate的重复事件。它们可能会正确显示它们，但无法提供编辑它们的方法

从您的屏幕截图上看，这就是Outlook抱怨的不受支持的重复模式

至于这个特殊的事件，它看起来确实很有趣，因为这基本上是一个只有一个实例的重复事件。更奇怪的是，这个实例附加了一个异常，它覆盖了SUMMARY/DTSTART/DTEND。但这并不意味着它无效

请注意，VEVENT中的摘要不是强制性的

现在此事件无效，但由于其他原因： 1 RDATE应使用与DTSTART/DTEND相同的格式，即带有时区的本地时间

---

2如您所述，DTSTART和DTEND不能相等，因为这是一个写得很好的问题。谢谢您的回答，这使我能够决定一个好的策略来正确管理此类事件。