经过夏时制（DST）转换的少于5小时的RFC 5545应该如何处理？
例如，假设DST在特定日期的凌晨2:00结束，并假定事件在该日期的第二个1:10 AM开始。 （第一个1:10 AM是夏令时一个现实世界小时，第二个1:10 AM是标准时间。）>
如果该事件具有-PT15M（在15分钟之前）的持续时间提醒，那么该事件开始前应在现实世界中弹出多少分钟？它是否应该在第一个1:55 AM（夏令时）早15分钟在现实世界中弹出？还是应该在夏令时12:55 AM早75分钟在现实世界中弹出？
该规范似乎暗示了后者的行为，但是这种行为对我来说似乎违反直觉。如果我想提前15分钟提醒，我的意思是“ 15分钟”。但是，它<直观的，用于更长的提醒，例如-P1D应该在该活动开始之前25小时，以便您在前一天的同一本地时间收到提醒。
-P1D情况与事件开始时间在不同的本地时间显示一天的提醒是不合逻辑的？显然，这是一个极端的情况，因为几乎没有会议在深夜开始。但是在某些情况下可能会发生这种情况，例如深夜社交活动。如果我保证在2个小时后在酒吧与您会面，我可能并不是说某些晚上是1个小时或3个小时！
RFC 5545规格说明如下：
在时间尺度不连续的情况下，例如，从标准时间到夏令时的更改以及倒退，准确时间的计算需要减去或加上不连续时间的变化。[为了进一步阐明，根据https://standards.calconnect.org/csd/cc-51003.pdf，RFC 5545具有标称持续时间（以本地时钟时间表示）和精确持续时间（忽略DST的实际秒表）的概念。上面的语言是关于名义上的持续时间应如何转换为确切的时间。
此问题并非特定于特定的日历实现，但我在此处标记Google日历和Outlook，因为使用这些API的开发人员可能对这些问题的了解最多。
经过夏令时（DST）过渡的少于5小时的RFC 5545行为如何？例如，假设DST在特定日期的凌晨2:00结束，并假设事件...
也要避免事件时间] >>。在此处查看答案摘要中的第一点Daylight saving time and time zone best practices
为了避免歧义并准确地参考“第二”上午1.10，应该将UTC时区用于第二个实例。