我有一个应用程序每小时收到一个事件（通过石英）。 所以这可能每天发生24次。
当天有3次排除时间，当我收到一个事件时我不想采取任何行动（必须仍然通过石英接收事件，因此解决方案不是更新石英cron表达式）
我需要在客户的时区配置这3次的时间。 在这种情况下，它将是CEST，其中观察到夏季（UTC + 2）和冬季（UTC + 1）时间。 时间是00：00,08：00,16：00，我将在这些时间的任何一侧有5分钟的缓冲区。
所以以08:00为例，我在07:55到08:05期间的任何时间都会收到一个活动，我将不会采取任何行动。
我的应用程序将在UTC时间工作，但是需要在CEST和将来的其他时区配置排除时间。
最初的想法是采用当前日期并计算该日期的UTC排除时间，但我相信这种方法会出现问题
有什么想法吗？
答案 0 :(得分：1)
小心，假设您正在谈论“当地日”，该活动可能会在包含daylight saving time transitions的日期每天收到23或25次。并非每个当地时间都有24小时。
还要意识到有几个时区在午夜就有DST过渡。例如，在巴西，时钟将从2015-10-17 23:59:59移动到2015-10-18 01:00:00，完全跳过午夜。午夜不存在，所以您必须决定是否在1:00收到活动，或者根本不收到。
然后在2016-02-20 23:59:59上，时钟将回到2016-02-20 23:00:00。虽然午夜仅存在一次，但延伸至23:55的“窗口”将重复两次。您必须决定是否希望能够在任一时段或第一个或第二个时段接收事件。
预先计算出事件的UTC时间的想法是有价值的，但关键是重复规则是按照当地时间和时区保存的，而你不是丢弃这些信息。您可能需要重新计算特定事件的UTC时间。当政府决定改变其时区的DST规则或基准抵消时，就会发生这种情况。通常，只要您应用时区更新，就应该考虑所有未来的UTC时间，并重新计算它们。
您可以通过订阅tz announcements邮件列表，然后监控自己的平台以获取相应的更新来通知时区更改。
另请参阅：Daylight saving time and time zone best practices
我对How to store repeating dates keeping in mind Daylight Savings Time的回答。