我在我的数据库中存储事件.我有'开始'和'结束'日期时间,'ticket_start'和'tickets_end'(用于门票销售实际开始/结束时 - 而不是实际事件的开始/结束).
到目前为止,我已经构建了一些方法来完成所有有趣的事情,例如在保存之前将日期/时间转换为GMT,然后返回到各自的时区进行显示.
我将时区存储在varchar字段中,其值为"America/New_York".
但是 - 现在我需要开始处理,如果用户想要允许重复事件.我以前做过,并没有那么重要,但从来没有涉及多个时区.
起初,我认为这没什么大不了的,但后来意识到 - 如果最初的开始日期是7月(例如),并且它每个月重复一年,在某些时候,夏令时将会成功因此,GMT的转换将以不同的方式改变时间.一个月,当转换为12:00时,它会将其更改为-5,然后,由于DST,它会将其更改为-4.
我目前的想法是,我将存储一个'dst'minitint(1),以确定是否在DST期间输入了开始/结束日期,然后在必要时制作一个方法将时间改变一小时.
但是 - 想想我会在这里问这里或许这是一个"正常",或者是一件我想不到的简单事情.
(cakephp 2.4.x)
我正在设计一个调度Web应用程序.我希望用户可以在几个不同的时区和区域设置中添加事件.挑战是正确呈现这些事件.
因此,作为一个例子:
如果用户在EST时区并且正在查看由另一个用户在PST中添加的网络研讨会事件,我想将事件的实际PST时间转换为查看者的本地时间.因此,如果事件安排在太平洋标准时间下午2点,那么它应显示为美国东部时间下午5点.
我还要小心,如果有数千个事件可能需要从实际事件时间转换到查看者的本地时间,性能不会受到影响.
所有的想法和意见都表示赞赏.
TIA
我很想知道我正在考虑的是不好的做法,或者如果因为这是一个特定而慎重的选择,那实际上是一个不错的主意.我想存储特定城市中发生的事件的日期信息.我想将这些数据存储为UTC时间戳.简单地存储时间戳和城市ID /国家ID(与特定时区相关联)而不是存储每个事件的时区不是一个好主意吗？我问,因为时区可以改变,但城市ID在数据库中永远不会改变.一旦服务器在时区更改的(不太可能的)事件中与最新时区同步,该事件将是独立的并且不受该更改的影响.但是,假设时区改变了它的边界,那么之前在该时区发生的事件可能在它之外.这样做似乎不明智吗？我只是想知道,我一直在寻求最佳实践,但在这种情况下,这实际上似乎是一个好主意.这特别是因为应用程序设计模型永远不会改变 - 事件将始终与特定城市相关联.
基本流程将是:
具有日期/位置的事件数据以ISO-8601 YYYY-MM-DD字符串等标准格式进入系统.
系统将日期转换为UTC时间戳,并使用该时间戳和事件的城市ID将日期与事件一起存储.
当用户请求查看该事件时,系统会提取与该事件关联的时间戳和城市信息,并使用城市的时区在显示时相应地格式化日期.
这是一个糟糕的主意吗？这有什么好处,存储TZ Offset的概念是否同样可以消除这个问题？