我想了解为什么必须在我们生成的文件中提供日光信息。为什么GMT / UTC时间不够，以及为什么像MS Outlook 2010这样的电子邮件客户端无法处理它。
答案 0 :(得分：0)
我认为iCalendar规范的最初目的是提供一种独立的文件格式，所有日历用户代理（CUA）（例如Outlook）都会对其进行相同的解释。由于您无法假设所有CUA共享相同的时区信息，因此必须将其包含在文件格式中。
实际上，使用内置时区定义通常更实际，在这种情况下，您只需指定UTC中的所有时间值（即使用附加的＆＃34; Z＆＃34;）
答案 1 :(得分：0)
主要原因是计算机上可能有或没有与指定的TZID匹配的时区。 iCAL允许任何类型的时区ID，包括"America/Bogota"等IANA时区和"SA Pacific Standard Time"等Windows时区。
当TZID指定的系统上的时区信息可用时，应该首选它，但它可能不可用。有人可能正在查看在Mac上运行时在Windows机器上生成的iCal文件。或者可能没有所有当前时区更新，TZID可能会引用尚未安装在计算机上的新创建的时区。
将规则编码到iCAL文件中对于支持互操作性至关重要。它确实伴随着从创建事件时固定到其已知值的那些规则的缺点。如果规则在事件发生之前发生更改，则事件可能在错误的时间发生 - 具体取决于文件的解释方式。这就是为什么在TZID匹配时使用系统信息的好主意。
关于为什么UTC不足以进行调度，因为事件几乎总是根据本地时间来指定。当地时间与UTC的关系高度依赖于时区，该时区由特定的当地政府设定。这些必须考虑夏令时和其他异常情况，政府可以改变主意。
例如，如果在美国太平洋时区每天当地时间上午8:00安排定期约会，那么将在标准时间（UTC时间下午4:00）和白天时间进行预约。 UTC时间下午5点。如果我按照UTC计划，那么我的当地时间将在DST过渡之前或之后一小时。这通常被称为闹钟问题＆＃34;，并且是the 2010 iPhone DST bug等罪魁祸首。