我需要编写一个用于发布.ICS文件的脚本。我已经读过很难做到这一点，要么是因为一些日历客户端有错误（许多人声称谷歌日历非常错误，特别是关于时区）或者因为开发人员没有正确遵守规范。我只需要为北美做这件事，但我必须考虑到夏令时（记住像亚利桑那州这样的地方，其中一部分观察夏令时，其中部分没有）。
有人可以回答这些问题吗？
还有其他提示吗？
答案 0 :(得分：8)
你听到了 - 这并不容易。易于提供非常基本的支持，而不是那么容易提供对提供者可能输出的内容的完全支持;特别是复发，例外，修改和是时区。
我已经在我的ics发行商工作了很长时间，现在它非常稳定。我一路上做了一些笔记。
见http://icalevents.com/category/notes/。此外，我的网站上的时区标签可能会对您有所帮助。
特别是，如果您正在进行重复活动，那么“ical cheatsheet”值得一看。在完成这项工作之后，我重写了我的重复引擎。
谷歌我没有发现它是一个问题，它是较小的玩家，特别是当他们开始做一些非标准的东西时（Zimbra / Pc基于tz等）。
虽然谷歌更新速度很慢（即有人更新他们的谷歌日历，你重新获取ics文件（绝对不是你的缓存）并且它没有更新 - 可能需要一个小时左右。这对于我们学校在做他们的时事通讯时 - 他们也从网站上打印出来。所以我现在就开始创建另一面 - 我们自己的ics编辑器。
有各种各样的自由剧本 - 为什么要自己动手？热衷于挑战？
答案 1 :(得分：5)
ICS文件中的时间可以是浮动的也可以是固定的。
浮动日期时间不包含对UTC或时区的引用 - 时间应该是ATTENDEE应在其当地时区到达会议的时间。这可能导致不同的与会者在不同时间召开会议，因此应谨慎使用（或永远不要！）。
固定时间是更好的方式。格式会根据会议是否以UTC格式进行更改。
对于UTC会议，请使用Z指定UTC：
19980119T070000Z
如果会议不是UTC，请使用TZID格式指定时区。以下代表纽约时间凌晨2点：
TZID=America/New_York:19980119T020000
注意：TZID格式不应用于UTC时间。
中指定RFC有关于DST的以下内容 - 请阅读它的内容！
如果，基于定义 引用时区，当地时间 所描述的不止一次（当时 从日光变为标准 时间），DATE-TIME值指的是 引用的第一次出现 时间。因此，TZID = America / New_York：20071104T013000表示 2007年11月4日凌晨1点30分美东时间 （UTC-04：00）。如果是当地时间 描述不会发生（何时 从标准变为日光 时间），DATE-TIME值是 使用UTC偏移量解释 在当地时间之前的差距。从而， TZID =美国/纽约：20070311T023000 表示2007年3月11日凌晨3:30 EDT（UTC-04：00），1:30后一小时 上午。 EST（UTC-05：00）。