我知道这是一个非常常见的问题,但我觉得我找到的答案并没有真正解决问题.我将概述我的具体用例,并向其他SO答案和网络上的信息提供摘要.
对于我正在编写的服务,数据库条目是在移动设备和我们的网站上创建和存储的,需要同时进行同步.我们目前的目标是Android和iOS,它们都使用sqlite作为关系数据库.服务器端使用Django和MySQL在Python中实现,但其他解决方案可能在将来取代它.
将按照此SO答案中概述的想法实施同步:https://stackoverflow.com/a/5052208/2076094.对于同步,我们将使用仅由服务器设置并同步到客户端的时间戳,用于创建和更新对象的last_synced_date和时间戳.由于对象引用用户在某些时间所做的事情,因此它们也具有时间戳信息.
我的问题只涉及用于这些时间戳的内部时间表示.UI中的用户表示是内部表示的本地化和格式化版本.在实现语言和用于表示时间戳的不同数据库中有许多不同的方式.经过相当多的研究后,似乎只剩下有效的解决方案了:
该文章这是Hacker News上(两次),建议使用UNIX时间,并提出一个相当不错的参数.正如所预料的那样,关于HN的讨论在上述两点以及一些点之间存在很大差异.
到目前为止,我的结论是,Unix时间戳更容易处理,但似乎不是Django的常用方法.几乎我发现的每个代码示例,从Django教程到很多其他站点,都在models.py中使用DateTimeField,它被映射到SQL中的某种日期字段,具体的术语取决于所使用的数据库.
使用ISO8601日期进行传输和存储的缺点是需要解析它们以创建相应的实现语言的日期类型.这并不难,但有点烦人.对于我们使用的每种语言,您需要一个(小)库或者至少需要比您希望的更多的代码.它不是很漂亮,创建依赖关系,可能会稍微慢一些.在我知道的任何语言中,Unix时间时间戳都没有这个问题.
另一件事是,您可以轻松地使用数据库中的"智能"日期或时间戳字段(以及解析期间).关于时间魔法的问题有很多问题可以解决问题.达到我的链接限制,所以我不能发布任何内容,但你很容易找到一些;)
我们可以使用不包含时区信息的简化格式,只使用UTC.我们只会使用UTC,但似乎如果你使用ISO8601,你也可以使用一种普遍理解和明确的格式.Unix时间始终是UTC,所以你永远不必担心.
当然ISO8601有被人类可读的,当你在原始数据库,我不会有2038前不久重写几行代码的优势,但是这似乎并没有弥补缺点.
似乎通过写出来我实际上已经得到了答案;)无论如何,我很想知道别人的想法以及你在自己的项目中做了什么.请简要介绍一下您的用例,以便其他人可以更好地对您的输入进行分类.
谢谢!