当RFC 5545的持续时间小于24小时时，当它跨越夏令时(DST)转换时，应该如何操作？
例如，假设夏令时在某一天的凌晨2:00结束，并假设某个事件在该天的第二个凌晨1:10开始。(第一个凌晨1:10在夏令时中提前一小时，第二个上午1:10在标准时间中)。
如果该事件有-PT15M(15分钟前)持续时间提醒，那么该提醒应该在事件开始前弹出多少分钟？它应该在现实世界中提前15分钟出现在凌晨1点55分(夏令时)吗？还是应该在夏令时凌晨12:55提前75分钟弹出？
规范似乎暗示了后一种行为，但这种行为对我来说似乎违背了直觉。如果我想提前15分钟得到提醒，我的意思是"15分钟"。然而，对于较长的提醒，是直观的，例如-P1D应在事件开始前25小时，以便您在前一天的同一当地时间收到提醒。
不管怎样，大多数日历应用程序是如何处理这种非直觉行为的？他们是否忽略了规范，总是处理提醒<24小时精确无需调整夏令时？或者我对规范的理解不正确，而在-P1D的情况下，一天的提醒显示在与事件开始时间不同的当地时间，这将是不明智的？
显然，这在某种程度上是一个偶然的情况，因为很少有会议是在半夜开始的。但也有可能发生这种情况，例如深夜的社交活动。如果我答应2小时后在酒吧见你，我可能不是说在某些晚上1小时或3小时！
以下是RFC 5545规范所说的：
在时间尺度上存在不连续性的情况下，例如从标准时间到夏时制的变化，精确持续时间的计算需要减去或加上不连续性持续时间的变化。
为了进一步澄清，根据https://standards.calconnect.org/csd/cc-51003.pdf，RFC 5545具有标称持续时间(以本地时钟时间为单位)和精确持续时间(忽略DST的真实世界秒表)的概念。上面的语言是关于如何将名义持久持续时间转换为确切的持续时间。
这个问题并不特定于特定的日历实现，但我在这里标记谷歌日历和Outlook，因为使用这些API的开发人员可能对这些问题有最多的了解。
上面的答案和评论以及对提出的问题的直接回答的合并：
第一部分：
"当RFC 5545持续时间小于24小时时，应如何操作是否通过夏令时(DST)转换">
答案：
由于持续时间小于24小时，因此应使用确切的小时、分钟或秒数作为持续时间(实时)。与持续时间<24小时。
第二部分：
"如果该事件具有-PT15M(15分钟前)持续时间提醒，则在活动开始前的实际时间应该是多少分钟弹出提醒？它是否应该在现实世界中提前15分钟出现在前1点55分(夏令时)？或者它应该在现实世界中弹出75夏令时凌晨12:55提前几分钟">
答案：
15分钟真实世界。说明书清楚地表明，任何少于一天的时间都是准确的时间。通过遵守夏令时期间重复时钟时间的参考标准，可以避免夏令时截止时间"重复"的任何混淆或歧义。IE:
- IE时间(如上午1点10分)的第一个实例是当人们看到某个时区的上午1点100分时假设要使用的实例
- 如果想参考上午1点10分的第二个例子，必须使用另一个时区(如UTC)来清楚地识别实际时刻
第三部分：
"大多数日历应用程序是如何处理这种非直觉行为的？做他们忽略规范并且总是处理提醒<精确到24小时而不调整夏令时？或者我对规格理解不正确这是-P1D的情况，与一天的情况无关事件开始时在不同的本地时间显示提醒时间">
答案：
他们不会忽视规范。规范处理这一点正如人们直观地预期的那样。提醒注意<24小时(PT24H)是准确的。无需调整夏令时
类似地，24小时前的提醒(PT24H)应恰好发生在24小时前。
在一天(P1D)提醒的情况下，一天提醒应在前一天的同一时间发生，即23、24或25小时前。这是人们直觉上所期望的。当然，实际的小时数会根据日历中的日期而有所不同。
P1D与PT24H不同，因为P1D将取决于日历中的日期，即当天是否发生夏令时转换，而PT24H是准确的。
参考文献：
- 夏令时和时区最佳实践
- https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5见DATETIME
- https://icalendar.org/iCalendar-RFC-5545/3-3-6-duration.html
- https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html
这里的挑战是避免歧义，不仅是持续时间，还有事件时间。请参阅此处答案摘要中的第一点夏令时和时区最佳实践
为了避免歧义并准确地指代上午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时间！(或另一个不受夏令时变化影响的时区)。
上面堆栈溢出链接中的答案摘要确实注意到，在某些情况下，可能需要同时存储local&UTC。我认为这可能正是这样的情况，在重复切换时间内，重复夏令时(第二个小时)中唯一真正准确的时间表示是UTC时间。