可以说，处理时区已经足够棘手了。当它开始生成用于安排会议/活动的ics文件时，它会变得更加混乱。
互联网上有很多查询，询问为什么"将 ics 文件导入 Outlook/Google 日历、Microsoft Exchange 服务器后会议时间偏差一小时"等。
尽管我对此进行了大量研究，包括遵循这些路径上的答案/建议，但还没有完全弄清楚处理事件时间的"正确方法"以及在 ics 文件中指定时区信息的最佳实践是什么。
是否应该将事件时间（开始/结束，重复事件时间）转换为UTC，并将时间转换为正确的时区留给ics文件的消费者：Outlook，Google日历？
No. 大多数事件不能由 UTC 计划。 如果事情就这么简单，我们就会这样做。 它要复杂得多。
假设您从 1 月 1 日开始，每天在美国太平洋时间上午 10：00 开会。 那将是 UTC 下午 6：00 - 所以你把它放在你的邀请中，并期望一切都能自行解决。 一切正常，直到三月的第二个星期日，夏令时生效。 然后，您的 UTC 下午 6：00 会议将与太平洋时间上午 11：00 对齐 - 这不是您打算安排会议的方式。
但是等等 - 情况变得更糟。 DST 规则实际上可以更改。 上一次发生在2007年的美国，但它一直在世界不同地区发生。 有时，变化的不仅仅是 DST，而是基本偏移量本身。 如果您按 UTC 进行安排，那么您正在设定一种期望，即您所知道的有关时区的所有内容都将与当前完全相同 - 但没有人可以预测未来。
正确的计划需要满足以下所有条件：
- 事件的原始本地时间值
- 时区标识符 - 最好是来自 IANA 时区数据库的时区标识符
- 所有系统都要通过时区数据更新保持更新
- 政府要好好玩，留出足够的时间来传播更新
最后一个非常重要，你对此无能为力。 近年来，埃及、摩洛哥和斐济等国家只需几天或几周的通知就做出了改变。 即使是像俄罗斯这样的大国也会改变他们的时区 - 所以你必须为更新做好准备。 您可以查看时区更新的悠久历史，并在此处观察未来的变化。