ICS 日历文件怎么看：全天日期、时区、RRULE 和重复导入
一份实用的 iCalendar/ICS 阅读指南，解释 DTSTART、DTEND、UTC、TZID、浮动时间、RRULE、UID 与 DTSTAMP，并说明导入前怎样检查。
打开配套工具 →ICS 文件看起来只是几行大写字段，但真正导入日历后，常见问题一点也不少：全天活动多显示一天，上海上午九点跑到欧洲下午，重复会议展开几百条，或者同一批事件导入两次。
ICS 日历文件查看器会在浏览器本地把 VEVENT 和 VTODO 整理成清单，按指定日期范围展开 RRULE，并标出 UID、DTSTAMP、日期和重复规则问题。它适合在导入前看清文件含义，不会连接或修改你的日历账户。
iCalendar 的核心规范是 RFC 5545。不同日历产品还有各自扩展和容错，因此“规范上能解析”与“每个客户端显示完全相同”仍有距离。
一份最小事件包含什么
典型事件如下：
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example//Calendar Export//ZH-CN
BEGIN:VEVENT
UID:meeting-20260720@example.com
DTSTAMP:20260717T020000Z
DTSTART:20260720T090000Z
DTEND:20260720T100000Z
SUMMARY:项目复盘
LOCATION:线上会议
END:VEVENT
END:VCALENDAR外层 VCALENDAR 是日历容器，内部 VEVENT 是事件。一个文件可以有很多事件，也可以包含时区定义、待办、提醒和重复例外。
几个字段各自解决不同问题：
UID：事件的稳定身份；DTSTAMP：对象创建或修订相关时间戳；DTSTART：开始；DTEND或DURATION：结束或持续时间；SUMMARY：标题；DESCRIPTION：说明；LOCATION：地点；ORGANIZER、ATTENDEE：组织者与参与者。
只要标题和日期看起来正常，不代表 UID 和时区就能省略。问题往往在第二次导入、更新或跨地区分享时出现。
全天事件为什么像是多了一天
全天事件使用 DATE 值：
DTSTART;VALUE=DATE:20260725
DTEND;VALUE=DATE:20260728它表示活动覆盖 7 月 25、26、27 日。DTEND 是不包含的终点，到了 28 日零点活动已经结束。
如果活动只在 7 月 25 日一天，常见写法是：
DTSTART;VALUE=DATE:20260725
DTEND;VALUE=DATE:20260726很多 CSV 转 ICS 脚本把用户填写的“最后一天”直接写入 DTEND，于是少显示一天；另一些查看器把 DTEND 当作包含日期，又多显示一天。导入前必须先确认源系统使用的是业务最后一天，还是协议中的排他终点。
本站查看器会把全天范围标成“结束日不包含”，避免和普通日期区间混淆。
同一个时间有三种写法
UTC
末尾 Z 表示 UTC：
DTSTART:20260720T010000Z这代表一个绝对时刻。上海夏季显示为上午九点，伦敦显示为当地凌晨或清晨，具体取决于时区规则。
带 TZID 的本地时间
DTSTART;TZID=Asia/Shanghai:20260720T090000它表示上海时区的上午九点。跨时区日历可以换算成查看者当地时间。
命名时区通常应配合 VTIMEZONE，或依赖客户端内置的时区数据库。不同设备对旧名称、Windows 时区名称和自定义 TZID 的支持并不一致。
浮动本地时间
没有 Z 也没有 TZID：
DTSTART:20260720T090000这叫浮动时间。谁导入，通常就按谁设备上的九点显示。它适合“每天当地上午九点”的事项，不适合全球所有人同时参加的视频会议。
最危险的转换，是把浮动九点直接加上 Z。这不是补全格式，而是改变事件代表的时刻。
RRULE 只保存规则，不是把每次会议都写一遍
每周二重复四次：
DTSTART:20260721T023000Z
RRULE:FREQ=WEEKLY;COUNT=4;BYDAY=TU常见字段包括：
FREQ：DAILY、WEEKLY、MONTHLY、YEARLY 等；INTERVAL：每隔几次；COUNT：总次数；UNTIL：重复截止；BYDAY：星期；BYMONTHDAY：月内日期；BYMONTH：月份；WKST：一周起始日。
没有 COUNT 或 UNTIL 的规则可能无限持续。查看器不会从事件开始一直算到世界末日，而是在用户选择的日期窗口内展开，并限制最大实例数。
真实日历还会用：
EXDATE排除某次；RDATE额外加入某次；- 带
RECURRENCE-ID的 VEVENT 修改单个实例； RANGE=THISANDFUTURE修改此后实例。
只用字符串拆分 RRULE 很容易漏掉这些关系。批量迁移应使用成熟 iCalendar 解析器，并拿原日历中的几次例外做回归测试。
UID 决定它是新事件还是旧事件
同一逻辑事件在更新文件中应保持相同 UID。日历应用可以结合 UID、SEQUENCE、DTSTAMP 和调度方法判断更新。
如果每次导出都生成新 UID，用户重复导入时更容易得到多份事件；如果所有事件共用一个 UID，后面的项目可能覆盖前面的项目。
常见 UID 形式：
order-9842-reminder@example.com它不需要能访问，也不应放密码或个人敏感数据，只要在生成系统中稳定且足够唯一。
DTSTAMP 通常使用 UTC。缺少它时，有些客户端仍会宽松导入，但后续同步和更新行为可能不一致。查看器会把缺失 UID 和 DTSTAMP 分别提示出来。
ICS 转 CSV 会丢掉什么
CSV 适合查看、筛选和交给表格人员校对，但它不能完整表达 iCalendar：
- 重复例外；
- VALARM 提醒；
- 会议响应状态；
- 参与者参数；
- VTIMEZONE；
- 多值与自定义
X-字段； - 附件和厂商扩展；
- 行折叠与原始编码。
因此 CSV/JSON 应视为分析副本，不是完整备份。原始 ICS 必须单独保留。
“下载单次 ICS”也只适合分享当前实例。它会把重复事件中的某一次变成普通 VEVENT，不保留整套 RRULE 和例外。
导入前怎样检查
先在查看器中选择一个覆盖业务周期的日期范围，例如前一个月到未来一年。确认：
- 事件数量与来源大致相符；
- 全天活动没有多一天或少一天；
- 跨时区会议显示的绝对时刻正确；
- RRULE 展开次数、星期和截止日期正确；
- UID 没有意外重复或缺失；
- DTEND 不早于 DTSTART；
- 重要地点、URL、说明和参与者仍在；
- 文件没有异常庞大的无限重复规则。
然后建立一个临时测试日历，只导入两三条典型事件：一条普通事件、一条全天事件、一条带重复和例外的事件。分别在目标 Apple Calendar、Google Calendar、Outlook 或企业客户端中查看。
确认无误后再导入整批。需要重做时，先删除测试日历或上一批事件，不要反复把修正版叠加到正式日历里。
ICS 的难点不在“把几列文字拼起来”，而在日期语义、时区和更新身份。先把这些字段看明白，再谈转换，通常能省掉一轮很难清理的重复日程。