Dav*_*ave 35 php mysql datetime cakephp dst
我在我的数据库中存储事件.我有'开始'和'结束'日期时间,'ticket_start'和'tickets_end'(用于门票销售实际开始/结束时 - 而不是实际事件的开始/结束).
到目前为止,我已经构建了一些方法来完成所有有趣的事情,例如在保存之前将日期/时间转换为GMT,然后返回到各自的时区进行显示.
我将时区存储在varchar字段中,其值为"America/New_York".
但是 - 现在我需要开始处理,如果用户想要允许重复事件.我以前做过,并没有那么重要,但从来没有涉及多个时区.
起初,我认为这没什么大不了的,但后来意识到 - 如果最初的开始日期是7月(例如),并且它每个月重复一年,在某些时候,夏令时将会成功因此,GMT的转换将以不同的方式改变时间.一个月,当转换为12:00时,它会将其更改为-5,然后,由于DST,它会将其更改为-4.
我目前的想法是,我将存储一个'dst'minitint(1),以确定是否在DST期间输入了开始/结束日期,然后在必要时制作一个方法将时间改变一小时.
但是 - 想想我会在这里问这里或许这是一个"正常",或者是一件我想不到的简单事情.
(cakephp 2.4.x)
Mat*_*int 108
首先,请注意在现代术语中,您应该说UTC而不是GMT.除了更准确地定义UTC之外,它们大多是等效的.保留GMT一词是指英国时区的部分,该部分在冬季月份生效,其偏移量为UTC + 0.
现在回答你的问题.UTC不一定是存储所有日期和时间值的最佳方式.它对于过去的事件或未来的绝对事件特别有效,但它对未来的本地事件 - 特别是未来的重复事件- 的效果不是很好.
我最近在另一个答案上写了这个,并且是当地时间比UTC更有意义的少数例外情况之一.主要论点是"闹钟问题".如果您按闹钟设置闹钟,那么您将在DST过渡的那天提前或延迟一小时醒来.这就是大多数人按当地时间设置闹钟的原因.
当然,如果您正在处理来自世界各地的数据,那么您不能只存储当地时间.你应该存储一些不同的东西:
对于最后两个,请理解,如果负责该时区的政府决定更改任何内容,则任何本地日期/时间的UTC等效值都会发生变化.由于每年都有多个时区数据库更新,因此您需要有计划订阅更新公告并定期更新您的时区数据库.每当您更新时区数据时,您都需要重新计算所有未来事件的UTC等效时间.
如果您计划显示跨越多个时区的任何类型的事件列表,则具有UTC等效项非常重要.这些是您将查询以构建该列表的值.
需要考虑的另一点是,如果事件安排在DST回退转换期间发生的本地时间,则必须确定事件是在第一个实例(通常)上发生,还是在第二个实例上发生(有时),或两者(很少),并在您的应用程序中构建一个机制,以确保事件不会发生两次,除非您想要它.
如果你正在寻找一个简单的答案 - 抱歉,但没有一个.跨时区安排未来事件是一项复杂的任务.
我有几个人向我展示了一种技术,他们确实使用UTC时间进行调度,即他们在本地时间选择一个开始日期,将其转换为UTC进行存储,并存储时区ID.然后在运行时,他们应用时区将原始UTC时间转换回本地时间,然后使用该本地时间计算其他重复次数,就好像它是最初存储的那样.
虽然这种技术可行,但缺点是:
如果时区更新在第一个实例运行之前更改了本地时间,则会关闭整个计划.这可以通过为"第一"实例选择过去的时间来减轻,使得第二实例实际上是第一个实例.
如果时间真的是一个应该跟随用户的"浮动时间"(例如在手机上的闹钟),你仍然必须存储它最初创建的区域的时区信息 - 即使这不是你想要运行的区域.
它增加了复杂性而没有任何好处.我会保留这种技术,用于您可能只有一个UTC调度程序,您正试图将时区支持改进.