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

至少可以说，处理时区非常棘手。当它开始生成用于安排会议/事件的ics文件时，它变得更加混乱

互联网上有很多疑问，询问为什么“将ics文件导入outlook/google日历、microsoft exchange server后，会议时间会缩短一小时”等等

虽然我对此做了很多研究，包括遵循这些线索的答案/建议，但还没有完全弄清楚处理事件时间的“正确方法”，以及在ics文件中指定时区信息的最佳实践是什么

---

如果是这样，事件时间（开始/结束，重复事件时间）将转换为UTC，并将时间转换为正确时区的时间留给ics文件的使用者：Outlook，Google calendar？

否。大多数事件不能由UTC安排。如果事情真的那么简单，我们就会这么做。这要复杂得多

想象一下，从1月1日开始，你每天在美国太平洋时间上午10:00开会。那将是UTC下午6:00-所以你把它放在你的邀请函中，并期望所有的事情都能自行解决。一切都很顺利，直到3月的第二个星期日夏时制生效。您的UTC下午6:00会议将与太平洋时间上午11:00一致-这不是您计划的会议安排方式

但是等等，情况变得更糟了。DST规则实际上可以改变。上一次发生在2007年的美国，但它一直发生在世界各地。有时，改变的不仅仅是DST，还有基准偏移量本身。如果您按UTC排定日程，您将建立一种期望，即您所知道的关于时区的一切都将与当前完全相同，但没有人能够预测未来

适当的日程安排需要满足以下所有要求：

• 事件的原始本地时间值
• 时区标识符-最好是来自
• 所有系统都要随时更新
• 政府应该好好玩玩，并留出足够的时间传播更新

---

最后一个问题非常重要，你对此无能为力。近年来，像和这样的国家只需几天或几周的通知就做出了改变。即使是大国也喜欢——所以你必须为更新做好准备。您可以回顾时区更新的悠久历史，并观察未来的变化。

感谢@MattJohnson提供的见解。以下是我的观察：1。是的，我同意所有使用ics的客户都需要更新最新的tz数据，以便安排工作正常。但是，无论时间是用tzid还是UTC指定的，都需要这种期望。如果客户端使用的是过时的数据，那么无论如何我们都会有问题。2.对于重复事件，当我们指定RRULE时，每个RRULE的转换时间将考虑DST转换时间，对吗？谷歌似乎就是这样处理的