我很想知道我正在考虑的是不好的做法,或者如果因为这是一个特定而慎重的选择,那实际上是一个不错的主意.
我想存储特定城市中发生的事件的日期信息.我想将这些数据存储为UTC时间戳.
简单地存储时间戳和城市ID /国家ID(与特定时区相关联)而不是存储每个事件的时区不是一个好主意吗？
我问,因为时区可以改变,但城市ID在数据库中永远不会改变.一旦服务器在时区更改的(不太可能的)事件中与最新时区同步,该事件将是独立的并且不受该更改的影响.但是,假设时区改变了它的边界,那么之前在该时区发生的事件可能在它之外.
这样做似乎不明智吗？我只是想知道,我一直在寻求最佳实践,但在这种情况下,这实际上似乎是一个好主意.这特别是因为应用程序设计模型永远不会改变 – 事件将始终与特定城市相关联.
我想存储特定城市中发生的事件的日期信息.我想将这些数据存储为UTC时间戳.
简单地存储时间戳和城市ID /国家ID(与特定时区相关联)而不是存储每个事件的时区不是一个好主意吗？
我问,因为时区可以改变,但城市ID在数据库中永远不会改变.一旦服务器在时区更改的(不太可能的)事件中与最新时区同步,该事件将是独立的并且不受该更改的影响.但是,假设时区改变了它的边界,那么之前在该时区发生的事件可能在它之外.
这样做似乎不明智吗？我只是想知道,我一直在寻求最佳实践,但在这种情况下,这实际上似乎是一个好主意.这特别是因为应用程序设计模型永远不会改变 – 事件将始终与特定城市相关联.
基本流程将是：
>带有日期/位置的事件数据以ISO-8601 YYYY-MM-DD字符串等标准格式进入系统.
>系统将日期转换为UTC时间戳,并使用该时间戳和事件的城市ID将事件的日期存储起来.
>当用户请求查看该事件时,系统会提取与该事件关联的时间戳和城市信息,并使用城市的时区在显示时相应地格式化日期.
这是一个糟糕的主意吗？这有什么好处,存储TZ Offset的概念是否同样可以消除这个问题？
无论你采用哪种方式,它都会以不同的方式失败,具体取决于变化.
原文链接：https://www.f2er.com/php/240141.html>如果您按照时区存储时间戳为2013-12-29 12:34:56 America / New_York,那么如果布朗克斯突然以不同的偏移量启动他们自己的时区America / New_York_Bronx并且您的事件发生在在布朗克斯区.
决定这是多么可能以及失败的程度.
>如果以UTC格式存储时间戳,并且事件发生的时区正在重新定义其偏移量(例如,将DST日期转换为或完全转换为不同的偏移量),则事件时间可能与该位置的实际挂钟时间不同.如果您在2013年12月13日12:34:56在德国柏林13:34:56举办活动,柏林将其DST转移,2013-12-29 12:34:56 UTC现在可能对应于14:34:56柏林当地时间,而事件仍然发生在当地时间13:34.
决定这是多么可能以及失败的程度.
>如果存储UTC时间戳并将其链接到然后链接到时区的物理位置,则可以解决这两个问题.但为此你必须存储精确的物理位置,而不仅仅是“纽约”,否则你只需要一个案例1.还有一个中间步骤.如果您确实存储了精确的物理位置并且具有将此位置解析为时区的精确方法,并且您使时区数据库保持最新,则可以处理几乎所有更改方案.
确定这是多么实用,以及这个额外精度对你来说有多大价值.
