生成 ICS 文件时应以 UTC 指定事件时间，以避免无数日历应用程序出现问题

Question

至少可以说，处理时区是很棘手的。当它生成用于安排会议/活动的 ics 文件时，它会变得更加混乱。

互联网上有很多疑问，询问为什么“将 ics 文件导入 Outlook/Google 日历、微软 Exchange 服务器后会议时间推迟一小时”等。

尽管我对此进行了大量研究，包括遵循这些路径上的答案/建议，但还没有完全弄清楚处理事件时间的“正确方法”以及在 ics 文件中指定时区信息的最佳实践是什么。

是否应该将事件时间（开始/结束、重复事件时间）转换为 UTC，并将时间转换为正确的时区，交给 ics 文件的使用者：Outlook、Google 日历？

Answer 1

不可以。大多数活动无法由 UTC 安排。如果真这么简单，我们就会这么做。它要复杂得多。

想象一下，从 1 月 1 日开始，您每天在美国太平洋时间上午 10:00 开会。那将是 UTC 时间下午 6:00 - 因此您将其放入邀请中并​​期望一切顺利。一切正常，直到三月的第二个星期日夏令时生效。然后，您下午 6:00 的 UTC 会议将与太平洋时间上午 11:00 一致 - 这不是您希望安排会议的方式。

但是等等——情况会变得更糟。DST 规则实际上可以改变。上一次这种情况发生在 2007 年的美国，但这种情况在世界不同地区一直在发生。有时，改变的不仅仅是夏令时，还有基本偏移量本身。如果您按照 UTC 进行安排，您就会期望您所知道的有关时区的所有信息都将与当前完全相同 - 但没有人可以预测未来。

正确的调度需要满足以下所有条件：

• 事件的原始当地时间值
• 时区标识符 - 最好来自IANA 时区数据库
• 所有系统均应及时更新时区数据
• 政府要表现得友善并留出足够的时间来传播更新

最后一项非常重要，您对此无能为力。近年来，埃及、摩洛哥和斐济等国家在短短几天或几周的时间内就做出了改变。即使像俄罗斯这样的大国也会改变时区- 因此您必须为更新做好准备。您可以在此处查看时区更新的悠久历史，并关注未来的变化。