我将从非编程的角度总结：

>按当地时间定义您的重复发生模式 – 而不是UTC.例如,如果您设置每日闹钟以在每天上午8:00唤醒您,则您不希望在夏令时转换后提前一小时或一小时后唤醒.如果我在美国太平洋时区,我无法安排在UTC时间下午4:00,因为在转换后,它必须切换到UTC时间下午3:00,以保持当地时间早上8:00.
>定义“本地”时间所代表的时区.不要假设服务器的本地时区与最终用户相同的时区.
>将当前时间预测为您希望事件触发的每次事件的UTC日期和时间.

>您几乎总是会在下一次发生这种情况时执行此操作,以便您可以使用UTC时钟来确定实际运行时间.
>在某些情况下,您可能还希望预测下几个(或多个)实例,例如接下来的5个实例,或下一年的所有实例. (这部分非常具体到应用程序的要求.)

>制定适当的策略(固定或可配置),以及在daylight saving time转换时发生的事件：

>对于“春季前进”过渡,当事件可能不存在时,缺少当地时间.例如,在美国太平洋时间,计划在当地时间凌晨2:00运行的每日任务将不会在2014年3月9日存在.在大多数情况下,您需要将该时间提前保存金额(通常为1小时) ),那天它将在凌晨3点运行,但在下一个实例中将在凌晨2点恢复运行. (但是,你完全有可能想要一个不同的策略.)
>对于“后退”转换,当事件可能存在两次时,重复的本地时间会重叠.例如,计划在凌晨1:00运行的每日任务将有两次可能在2014年11月2日运行.在大多数情况下,您将希望在第一次出现时运行1 ：PDT上午00点,跳过同一天的太平洋标准时间上午1点的下一次出现. (但同样,您可能需要一种不同的策略,例如在第二次出现时运行,或者在两者中运行.YMMV)

>如果您需要更新时区数据,请准备重新计算所有出现的UTC时间. IANA/Olson TZDB每年都会发布多个更新,因为世界各国政府一直在改变他们关于时区偏移和夏令时规则的想法.您不能在将来的任何特定持续时间内假设规则不会更改.

>确保subscribe for announcements时区数据发布,并有一个将它们应用于您的系统和/或应用程序的过程.
>在传统的企业环境中,这应该是I.T.的责任.运营人员.
>根据您的环境,您可能通过tzdata linux软件包更新,Java JRE or tzupdater或任意数量的其他渠道获取此数据.有时它是特定于环境的,有时它是特定于编程平台的,例如timezonedb PECL package for PHP,以及许多其他.
> Microsoft拥有自己的时区数据.在Windows上,如果您使用.NET中的TimeZoneInfo(例如),则表示您正在使用此数据.更新来自here,也会自动通过Windows Update推出,因此您应该留意这些,以便您知道何时/是否需要重新计算.

>通过所有这些理解,仍然存在一种情况,您只能按UTC计划,这是针对ABSOLUTE的未来事件.例子：

>每X小时或每X分钟运行一次的工作.
>日出开始和停止时间,或其他天文现象.
>时间敏感的安全窗口,例如在预先安排的时间将敏感信息传输给另一方.

Windows任务计划程序

Windows不一定做正确的事情.注意你如何定义触发器：

当您选中标记为“跨时区同步”的框时,该任务仅按UTC计划. (所有时间仍然显示为本地时间,但存储为UTC.)因此,这是我之前称为“绝对”事件.

当您取消选中该框时,它将使用运行代码的计算机的本地时区.它没有给你任何指定时区的选项,所以这不是一个很好的实现恕我直言.

我不完全确定它是DST行为,但我会试验并回复你.它可能完成我上面描述的,但不一定.

sql代理

sql Agent调度程序更糟糕,因为它只允许您使用本地服务器时间.同样,不能指定时区,也不能指定UTC.

它已经是requested,但不被接受.