DST 转换与 iCalendar 提醒与 RFC 5545 持续时间规范

Question

不到 24 小时的 RFC 5545 持续时间在跨越夏令时 (DST) 转换时应如何处理？

例如，假设 DST 在特定日期的凌晨 2:00 结束，并假设事件在当天的第二个凌晨 1:10 开始。 （第一个凌晨 1:10 是夏令时的一个真实小时，第二个凌晨 1:10 是标准时间）。

如果该事件有一个-PT15M（15 分钟前）持续时间提醒，那么该提醒应该在事件开始前多少分钟弹出？它应该在凌晨 1:55（夏令时）提前 15 分钟弹出现实世界吗？还是应该提前 75 分钟在夏令时上午 12:55 弹出真实世界？

规范似乎暗示了后一种行为，但这种行为对我来说似乎违反直觉。如果我想要提前 15 分钟提醒，我的意思是“15 分钟”。然而，对于较长的提醒，它 很直观，例如-P1D 应在该活动开始前 25 小时，以便您在前一天的同一当地时间收到提醒。

无论如何，大多数日历应用程序如何处理这种不直观的行为？他们是否忽略规范并始终将小于 24 小时的提醒视为准确而不针对 DST 进行调整？还是我对规范的理解有误，-P1D 的情况会不直观，因为一天提醒会在不同的当地时间显示为活动开始时间？

显然，这在某种程度上是一个极端情况，因为很少有会议在半夜开始。但是在某些情况下可能会发生这种情况，例如深夜社交活动。如果我保证 2 小时后在酒吧见你，我可能不是指某些晚上 1 小时或 3 小时！

RFC 5545 规范是这样说的：

在时间尺度不连续的情况下，例如从标准时间到白天时间的变化，以及从标准时间到白天时间的变化，精确持续时间的计算需要减去或增加不连续持续时间的变化。

为了进一步澄清，根据https://standards.calconnect.org/csd/cc-51003.pdf，RFC 5545 具有标称持续时间（以本地时钟时间表示）和精确持续时间（忽略 DST 的现实世界秒表）的概念。上面的语言是关于如何将名义上的持续持续时间转换为精确的持续时间。

这个问题并不特定于特定的日历实现，但我在这里标记了 Google 日历和 Outlook，因为使用这些 API 的开发人员可能对这些问题有最多的了解。

Answer 1

以上答案和 cmets 的整合以及对所提出问题的直接答案：

第一部分：

"当 RFC 5545 持续时间少于 24 小时时，它应该如何处理？ 跨越夏令时 (DST) 转换？"

答案：

由于持续时间小于 24 小时，因此应使用准确的小时数、分钟数或秒数（实时）。持续时间

第二部分：

"如果该事件有 -PT15M（15 分钟前）持续时间提醒，则 事件开始前的真实世界分钟数 提醒弹出？它是否应该提前 15 分钟在现实世界中弹出？ 第一个凌晨 1:55（夏令时）？还是应该弹出75个真实世界 比夏令时早 12:55 分钟？"

答案：

15 分钟真实世界。规范清楚地表明，任何不到一天的时间都是准确的时间。通过遵守在夏令时期间引用重复时钟时间的标准，可以避免围绕“重复”时间的夏令时截止时间出现任何混淆或歧义。即：

• IE 时间的第一个实例（例如上午 1.10 点）是当人们看到某个时区的上午 1.10 点时假定的时间。
• 如果想要参考上午 1.10 的第二个实例，则必须使用另一个时区（例如 UTC）来清楚地识别实际的时间点。

第三部分：

“大多数日历应用程序如何处理这种不直观的行为？ 他们忽略规范并始终将小于 24 小时的提醒视为准确 不调整夏令时？还是我对规范的理解不正确 这是 -P1D 案例，这对于一天来说是不直观的 提醒在活动开始时显示在不同的当地时间 时间？”

答案：

他们不会忽略规范。该规范按照人们直觉预期的方式处理了这一问题。 同样，24 小时前的提醒 (PT24H) 应恰好在 24 小时前发生。

在一天 (P1D) 提醒的情况下，1 天提醒应在前一天的同一时间发生，即 23、24 或 25 小时前。正如人们直觉所期望的那样。实际小时数当然会根据日历中当天的位置而有所不同。

P1D 与 PT24H 不同，因为 P1D 将取决于日历中的日期，当天是否发生 DST 转换，而 PT24H 是准确的。

参考资料：

• Daylight saving time and time zone best practices
• https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 见日期时间
• https://icalendar.org/iCalendar-RFC-5545/3-3-6-duration.html
• https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html

Answer 2

这里的挑战是避免歧义，不仅仅是持续时间，还有事件时间。在此处查看答案摘要中的第一点Daylight saving time and time zone best practices

为避免歧义并准确引用“第二个”上午 1.10 点，应为这些第二个实例使用 UTC 时区。

注意：在规范的 DATETIME 部分，在表格 #3 下，https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 明确指出带有时区的本地时间总是指第一个实例。

上述文档的第 45 页说，对于重复出现，它总是被解释为上述（第一个实例）：

如果计算的重复实例的本地开始时间不 在指定的时区存在或出现多次， 重复实例的时间以相同的方式解释 作为描述该日期和时间的显式 DATE-TIME 值，如 在第 3.3.5 节中指定。

我认为这意味着引用示例中第二个上午 1.10 的唯一方法是使用 UTC 时间！ （或不受该夏令时更改影响的另一个时区）。

上面堆栈溢出链接中的答案摘要确实指出，在某些情况下，可能需要同时存储本地和 UTC。我建议这可能正是这样一种情况，在重复切换小时内，在该重复夏令时（第二个小时）中唯一真正准确的时间表示是 UTC 时间。