# 日历/事件 ICS 导出：使用 TZID=Europe/Berlin 导入 Outlook 时时间错误（+1 小时）

**URL:** <https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797>\
**Category:** Bug\
**Tags:** events, fixed\
**Created:** [2026年八月11日 14:29 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797 "2026-08-11T14:29:03Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\
**Post date:** [2026年九月3日 10:10 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/5 "2026-09-03T10:10:56Z")

</div>

我对此进行了进一步调查，并打开了一个 PR 来解决该问题：

> <https://github.com/discourse/discourse/pull/43168>
>
> \## What does this change?
> 
> Adds \`VTIMEZONE\` components to generated ICS downlo…ads when an event uses a named timezone.
> 
> Some calendar clients, notably Outlook on Windows, do not reliably interpret IANA \`TZID\` values unless the calendar also includes a matching \`VTIMEZONE\` definition. This could cause events such as \`Europe/Berlin\` to import one hour late even though the \`DTSTART\`/\`DTEND\` values were correct.
> 
> The generator now derives the current timezone rules from the bundled Moment Timezone data and:
> 
> emits one \`VTIMEZONE\` per unique \`TZID\`
> emits the current recurring \`DAYLIGHT\` / \`STANDARD\` pair using open-ended yearly \`RRULE\`s when the transition rules are stable
> verifies that the following seasonal cycle repeats the same rules before treating them as recurring
> falls back to the current fixed offset when a stable recurring pair cannot be established
> handles zones with no current DST transition
> 
> Existing event \`DTSTART\` / \`DTEND\` behavior is unchanged; the additional timezone definition gives clients the information needed to interpret those local times correctly.
> 
> \## Tests
> 
> Added coverage for:
> 
> \- \`Europe/Berlin\` — European DST rules / original Outlook case
> \- \`America/New\_York\` — North American DST rules
> \- \`Asia/Kolkata\` — stable current offset
> \- \`Europe/London\` — zero standard UTC offset / GMT-BST rules
> 
> \`Unit | Utility | download-calendar\`: 22/22 passing.
> 
> \`discourse-events\` QUnit: 270 passing, 1 skipped, 0 failures.
> 
> Prettier, ESLint, and \`git diff --check\` are clean.

问题出在 ICS 导出上，而不是服务器/容器的时区。导出的事件使用了 IANA `TZID`（例如 `Europe/Berlin`），但目前未包含对应的 `VTIMEZONE` 定义，而 Outlook 等客户端需要该定义才能可靠地解释夏令时规则。

该 PR 在支持时区的 ICS 下载中添加了 `VTIMEZONE` 定义，同时保留了现有的本地 `DTSTART`/`DTEND` 值。

对于本主题中的示例，导出内容现在包含了 `Europe/Berlin` 的 CET/CEST 实施情况，因此：

`DTSTART;TZID=Europe/Berlin:20260811T170000`

可以按正确的 UTC+2 夏季偏移量进行解释，而不是让 Outlook 回退到 UTC+1。

我还添加了针对欧洲和北美夏令时规则、固定偏移量情况以及 `Africa/Casablanca` 使用的更不寻常的季节性转换的测试覆盖。

---

_[View the full topic](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797)._