处理时区至少可以说是棘手的。当它生成用于安排会议/活动的ics文件时，它会变得更加混乱。
互联网上有很多疑问，询问为什么“将一个ics文件导入Outlook /谷歌日历，微软交换服务器等”后“会议时间已经过了一小时”等。
虽然我已经对此进行了相当多的研究，包括遵循这些路径上的答案/建议，但还没有找到处理事件时间的“正确方法”，以及在ics中指定时区信息的最佳做法是什么文件。
如果是这样，事件时间（开始/结束，重复发生的事件时间）将转换为UTC，并将时间转换为正确的时区，留给ics文件的消费者：Outlook，Google日历？
答案 0 :(得分：3)
没有。 UTC无法安排大多数事件。如果它那么简单，那就是我们如何做到的。它复杂得多。
想象一下，从1月1日开始，美国太平洋时间每天上午10点开会。那将是UTC时间下午6点 - 所以你把它放在你的邀请中，并希望所有人都能自己解决问题。一切正常，直到三月的第二个星期天，夏令时开始生效。您的下午6:00 UTC会议将与太平洋时间上午11:00对齐 - 这不是您打算安排会议的方式。
但等等 - 情况变得更糟。 DST规则实际上可以更改。这最后发生在2007年的美国，但它始终发生在世界各地。有时它不只是DST发生变化，而是基础偏移本身。如果您按照UTC计划，那么您就会期望您所知道的有关时区的所有内容都与目前完全一样 - 但是没有人可以预测未来。
正确的安排需要以下所有内容：
最后一个非常重要，你可以做的很少。近年来，Egypt, Morocco和Fiji等国家/地区仅在几天或几周后就做出了更改。即使像Russia change their time zones这样的大国也是如此 - 所以你必须为更新做好准备。您可以查看时区更新的详细历史记录，并留意未来的更改here。