DST 转换与 iCalendar 提醒与 RFC 5545 持续时间规范
DST transitions vs. iCalendar reminders vs. RFC 5545 duration spec
持续时间少于 24 小时的 RFC 5545 在跨越夏令时 (DST) 转换时应如何处理？
例如，假设夏令时在某一天的 2:00AM 结束，并假设事件在该天的第二个 1:10AM 开始。 （第一个 1:10AM 比夏令时早 real-world 小时，第二个 1:10AM 是标准时间）。
如果该事件有 -PT15M（前 15 分钟）持续时间提醒，那么该提醒应该在事件开始前多少 real-world 分钟弹出？它是否应该在第一个 1:55AM（夏令时）提前 15 real-world 分钟弹出？或者它应该在 12:55AM 夏令时提前 75 real-world 分钟弹出？
规范似乎暗示了后一种行为，但这种行为对我来说似乎 counter-intuitive。如果我想要提前 15 分钟提醒，我的意思是“15 分钟”。然而，它 对于较长的提醒来说是直观的，例如-P1D 应该是该事件开始前 25 小时，以便您在前一天的同一当地时间收到提醒。
无论如何，大多数日历应用程序如何处理这种不直观的行为？他们是否忽略规范并始终将 <24 小时的提醒视为准确而不针对 DST 进行调整？还是我对规范的理解不正确，-P1D 的情况与 one-day 提醒显示在与活动开始时间不同的当地时间是不直观的？
显然这有点极端，因为很少有会议是在半夜开始的。但在某些情况下可能会发生这种情况，例如late-night 社交活动。如果我答应在 2 小时内在酒吧与你会面，我可能不是指在某些晚上 1 小时或 3 小时！
RFC 5545 规范是这样说的：
In the case of discontinuities in the time scale, such as the change from standard time to daylight time and back, the computation of the exact duration requires the subtraction or addition of the change of duration of the discontinuity.
为了进一步澄清，根据 https://standards.calconnect.org/csd/cc-51003.pdf，RFC 5545 具有标称持续时间（本地时钟时间）和精确持续时间（忽略 DST 的 real-world 秒表）的概念。上面的语言是关于如何将标称持续持续时间转换为精确持续时间。
这个问题并不特定于特定的日历实现，但我在此处标记了 Google 日历和 Outlook，因为使用这些 API 的开发人员可能对这些问题了解最多。
这里的挑战是避免歧义，不仅是持续时间，还有事件时间。请在此处查看答案摘要中的第一点 Daylight saving time and time zone best practices
为了避免歧义并准确指代 'second' 凌晨 1 点 10 分，第二个实例应使用 UTC 时区。
注意：在规范的 DATETIME 部分，在表格 #3 下，https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 它清楚地表明带有时区的本地时间始终指的是 第一个实例。
上述文档的第 45 页表示，对于重复，它始终如上解释（一例）：
If the computed local start time of a recurrence instance does not
exist, or occurs more than once, for the specified time zone, the
time of the recurrence instance is interpreted in the same manner
as an explicit DATE-TIME value describing that date and time, as
specified in Section 3.3.5.
我认为这意味着引用您的示例的第二个凌晨 1.10 分的唯一方法是使用 UTC 时间！ （或不受该夏令时变化影响的另一个时区）。
上面堆栈溢出 link 中的答案摘要确实指出，在某些情况下，可能需要同时存储本地和 UTC。我建议这可能正是这样一种情况，在重复的切换时间中，唯一真正准确表示重复的夏令时（第二个小时）的时间是 UTC 时间。
以上答案和评论的合并以及对所提出问题的直接回答：
第一部分：
"How should an RFC 5545 duration of less than 24 hours act when it
crosses a Daylight Saving Time (DST) transition?"
答案：
由于持续时间少于 24 小时，因此持续时间应使用准确的小时数、分钟数或秒数（实时）。持续时间 < 24 小时没有冲突或歧义。
第二部分：
"If that event has a -PT15M (15 mins before) duration reminder, then
how many real-world minutes before the start of the event should that
reminder pop up? Should it pop up 15 real-world minutes earlier at the
first 1:55AM (in Daylight Time)? Or should it pop up 75 real-world
minutes earlier at 12:55AM Daylight Time?"
答案：
15 分钟真实世界。规格清楚地表明任何少于一天的时间都是准确的时间。通过遵守在夏令时期间引用重复时钟时间的标准，可以避免围绕夏令时截止时间 'repeated' 的任何混淆或歧义。即：
- IE 的第一个时间实例（例如凌晨 1.10 分）是当人们看到某个时区的凌晨 1.10 分时被假定为预期的时间。
- 如果要参考凌晨 1.10 的第二个实例，则必须使用另一个时区（例如 UTC）来清楚地识别实际时刻。
第三部分：
"how do most calendar apps deal with this unintuitive behavior? Do
they ignore the spec and always treat reminders <24 hours as exact
without adjusting for DST? Or am I understanding the spec incorrectly
and it's the -P1D case that will be unintuitive with the one-day
reminder showing up at a different local time as the event start
time?"
答案：
他们不会忽视规范。规范按照人们的直觉预期来处理这个问题。 < 24 小时 (PT24H) 的提醒是准确的。无需调整夏令时。
同样，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
持续时间少于 24 小时的 RFC 5545 在跨越夏令时 (DST) 转换时应如何处理？
例如，假设夏令时在某一天的 2:00AM 结束，并假设事件在该天的第二个 1:10AM 开始。 （第一个 1:10AM 比夏令时早 real-world 小时，第二个 1:10AM 是标准时间）。
如果该事件有 -PT15M（前 15 分钟）持续时间提醒，那么该提醒应该在事件开始前多少 real-world 分钟弹出？它是否应该在第一个 1:55AM（夏令时）提前 15 real-world 分钟弹出？或者它应该在 12:55AM 夏令时提前 75 real-world 分钟弹出？
规范似乎暗示了后一种行为，但这种行为对我来说似乎 counter-intuitive。如果我想要提前 15 分钟提醒，我的意思是“15 分钟”。然而，它 对于较长的提醒来说是直观的，例如-P1D 应该是该事件开始前 25 小时，以便您在前一天的同一当地时间收到提醒。
无论如何，大多数日历应用程序如何处理这种不直观的行为？他们是否忽略规范并始终将 <24 小时的提醒视为准确而不针对 DST 进行调整？还是我对规范的理解不正确，-P1D 的情况与 one-day 提醒显示在与活动开始时间不同的当地时间是不直观的？
显然这有点极端，因为很少有会议是在半夜开始的。但在某些情况下可能会发生这种情况，例如late-night 社交活动。如果我答应在 2 小时内在酒吧与你会面，我可能不是指在某些晚上 1 小时或 3 小时！
RFC 5545 规范是这样说的：
In the case of discontinuities in the time scale, such as the change from standard time to daylight time and back, the computation of the exact duration requires the subtraction or addition of the change of duration of the discontinuity.
为了进一步澄清，根据 https://standards.calconnect.org/csd/cc-51003.pdf，RFC 5545 具有标称持续时间（本地时钟时间）和精确持续时间（忽略 DST 的 real-world 秒表）的概念。上面的语言是关于如何将标称持续持续时间转换为精确持续时间。
这个问题并不特定于特定的日历实现，但我在此处标记了 Google 日历和 Outlook，因为使用这些 API 的开发人员可能对这些问题了解最多。
这里的挑战是避免歧义，不仅是持续时间，还有事件时间。请在此处查看答案摘要中的第一点 Daylight saving time and time zone best practices
为了避免歧义并准确指代 'second' 凌晨 1 点 10 分，第二个实例应使用 UTC 时区。
注意：在规范的 DATETIME 部分，在表格 #3 下，https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 它清楚地表明带有时区的本地时间始终指的是 第一个实例。
上述文档的第 45 页表示，对于重复，它始终如上解释（一例）：
If the computed local start time of a recurrence instance does not exist, or occurs more than once, for the specified time zone, the time of the recurrence instance is interpreted in the same manner as an explicit DATE-TIME value describing that date and time, as specified in Section 3.3.5.
我认为这意味着引用您的示例的第二个凌晨 1.10 分的唯一方法是使用 UTC 时间！ （或不受该夏令时变化影响的另一个时区）。
上面堆栈溢出 link 中的答案摘要确实指出，在某些情况下，可能需要同时存储本地和 UTC。我建议这可能正是这样一种情况，在重复的切换时间中，唯一真正准确表示重复的夏令时（第二个小时）的时间是 UTC 时间。
以上答案和评论的合并以及对所提出问题的直接回答：
第一部分：
"How should an RFC 5545 duration of less than 24 hours act when it crosses a Daylight Saving Time (DST) transition?"
答案：
由于持续时间少于 24 小时，因此持续时间应使用准确的小时数、分钟数或秒数（实时）。持续时间 < 24 小时没有冲突或歧义。
第二部分：
"If that event has a -PT15M (15 mins before) duration reminder, then how many real-world minutes before the start of the event should that reminder pop up? Should it pop up 15 real-world minutes earlier at the first 1:55AM (in Daylight Time)? Or should it pop up 75 real-world minutes earlier at 12:55AM Daylight Time?"
答案：
15 分钟真实世界。规格清楚地表明任何少于一天的时间都是准确的时间。通过遵守在夏令时期间引用重复时钟时间的标准，可以避免围绕夏令时截止时间 'repeated' 的任何混淆或歧义。即：
- IE 的第一个时间实例（例如凌晨 1.10 分）是当人们看到某个时区的凌晨 1.10 分时被假定为预期的时间。
- 如果要参考凌晨 1.10 的第二个实例，则必须使用另一个时区（例如 UTC）来清楚地识别实际时刻。
第三部分：
"how do most calendar apps deal with this unintuitive behavior? Do they ignore the spec and always treat reminders <24 hours as exact without adjusting for DST? Or am I understanding the spec incorrectly and it's the -P1D case that will be unintuitive with the one-day reminder showing up at a different local time as the event start time?"
答案：
他们不会忽视规范。规范按照人们的直觉预期来处理这个问题。 < 24 小时 (PT24H) 的提醒是准确的。无需调整夏令时。
同样，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