我希望能够将这个问题及其答案作为处理夏令时的权威指南,特别是处理实际的变更问题.
如果您有任何要添加的内容,请执行此操作
许多系统依赖于保持准确的时间,问题在于由于夏令时改变时间 - 向前或向后移动时钟.
例如,在订单获取系统中有一个业务规则取决于订单的时间 - 如果时钟发生变化,规则可能不那么明确.如何保持订单的时间？当然有无数的场景 - 这只是一个说明性的场景.
同样重要的是,如果不是这样的话:
我会对编程,操作系统,数据持久性和该问题的其他相关方面感兴趣.
一般答案很好,但我也希望看到细节,特别是如果它们只在一个平台上可用.
我正在构建一个自定义事件系统,如果你有一个如下所示的重复事件:
活动A从2011年3月3日起每4天重复一次
要么
活动B于2011年3月1日星期二每2周重复一次
如何以一种易于查找的方式将其存储在数据库中.如果有大量事件,我不希望出现性能问题,在渲染日历时我必须经历每一个事件.
假设有一个重新发生的事件让我们说结束时间总是在同一个本地时间,比如说17:00,无论该时区是否开启夏令时.并且当DST在特定时区打开或关闭时,还要求不要手动更改时间.还要求每当任何其他系统通过API(即GetEndTimeByEvent)询问结束时间时,它总是以UTC格式发送结束时间.
方法1: 如果决定以UTC格式存储,则可以将其存储在数据库表中,如下所示.
Event UTCEndTime
=====================
ABC 07:00:00
MNO 06:00:00
PQR 04:00:00
对于第一个事件ABC,UTC的结束时间是上午07:00,如果转换为从UTC到2012年7月1日当地时间显示,则将在当地时间17:00结束,如果在2012年10月10日转换( DST为时区的开启日期)然后将导致下午6点,这是不正确的结束时间.
我可以想到的一种可能的方法是将DST时间存储在附加列中,并在时区有DST ON时使用该时间.
方法2: 但是,如果它被存储为如下的本地时间,例如对于事件ABC,它将在任何日期始终为17:00,因为没有从UTC到本地时间的转换.
Event LocalEndTime
=======================
ABC 17:00:00
MNO 16:00:00
PQR 14:00:00
应用程序层将本地时间转换为UTC时间,以通过(API GetEndTimeByEvent)发送到其他系统.
在这种情况下,以UTC格式存储时间仍然是个好主意吗？如果是,那么如何获得恒定的当地时间？
相关问题:是否有充分的理由将时间存储在UTC中？
我在我的数据库中存储事件.我有'开始'和'结束'日期时间,'ticket_start'和'tickets_end'(用于门票销售实际开始/结束时 - 而不是实际事件的开始/结束).
到目前为止,我已经构建了一些方法来完成所有有趣的事情,例如在保存之前将日期/时间转换为GMT,然后返回到各自的时区进行显示.
我将时区存储在varchar字段中,其值为"America/New_York".
但是 - 现在我需要开始处理,如果用户想要允许重复事件.我以前做过,并没有那么重要,但从来没有涉及多个时区.
起初,我认为这没什么大不了的,但后来意识到 - 如果最初的开始日期是7月(例如),并且它每个月重复一年,在某些时候,夏令时将会成功因此,GMT的转换将以不同的方式改变时间.一个月,当转换为12:00时,它会将其更改为-5,然后,由于DST,它会将其更改为-4.
我目前的想法是,我将存储一个'dst'minitint(1),以确定是否在DST期间输入了开始/结束日期,然后在必要时制作一个方法将时间改变一小时.
但是 - 想想我会在这里问这里或许这是一个"正常",或者是一件我想不到的简单事情.
(cakephp 2.4.x)