2013-03-21 410 views
11

我知道这是一个很常见的问题,但我不觉得我发现的答案真正解决了问题。我将概述我的具体使用案例,并提供其他SO答案和网络中的信息摘要。时间戳:iso8601 vs unix时间戳

对于我正在撰写的服务数据库条目的创建和存储都在移动设备和我们的网站上,并且需要同步两种方式。我们目前正在针对Android和iOS,它们都使用sqlite作为关系数据库。服务器端使用Django和MySQL在Python中实现,但其他解决方案可能会在未来取代它。

将按照本答案概述的思路实施同步:https://stackoverflow.com/a/5052208/2076094。为了同步,我们将使用仅由服务器设置并同步到客户端的时间戳,用于创建和更新对象的last_synced_date和时间戳。由于对象是指用户在特定时间执行的操作,因此它们也具有时间戳信息。

我的问题只涉及这些时间戳的内部时间表示。用户界面中的用户表示是内部表示的本地化和格式化版本。在实现语言和用于表示时间戳的不同数据库中有很多不同的方法。相当多的研究之后,似乎有只有有效的解决方案左:

  • Unix的时间
  • ISO8601

article这是Hacker News上(两次),建议使用UNIX时间并提出了一个很好的论点。关于HN的讨论,正如预料的那样,在上述两点和其他一些方面存在分歧。

到目前为止我的结论是,Unix时间戳更容易处理,但似乎并不是在Django中常见的方式。几乎所有我从Django教程中发现的代码示例到很多其他站点都使用models.py中的DateTimeField,它被映射到SQL中的某种日期字段,具体取决于所使用的数据库。

使用ISO8601日期传输和存储的缺点是需要分析它们以创建相应的实现语言的日期类型。这并不难,但有点烦人。对于我们使用的每种语言,您都需要一个(小)库,或者至少需要比您希望的更多的代码。这不是很漂亮,创建依赖关系,可能会稍微慢一些。 Unix时间时间戳在我知道的任何语言中都没有这个问题。

另一件事是,您可以很容易地在数据库中(和解析过程中)使用“智能”日期或时间戳字段发生麻烦。关于时间魔法的问题,有很多关于这个问题的问题。我的链接已达到限制,所以我无法发布任何内容,但您可以轻松找到一些;)

我们可以使用不包含时区信息的简化格式,并且始终使用UTC。我们只会使用UTC,但是如果您使用ISO8601,那么您可能会使用普遍理解和明确的格式。 Unix时间总是用UTC,所以你永远不必担心。

当然,当您查看原始数据库时,ISO8601的优点是人类可读,并且在2038年之前不必重写几行代码,但这似乎不能弥补缺点。

看来,写出来的东西我已经有了我的答案;)无论如何,我很想知道别人的想法以及你在自己的项目中做了些什么。请简要介绍一下您的用例,以便其他人可以更好地分类您的输入。

谢谢!

回答

0

感谢您提出的这个好问题。很难找到任何有关时间数据类型或时间标准/格式的信息,无论这称为什么。过去几天我一直在努力选择正确的时间格式。 就像你,我在移动设备和网络服务器中都编码(更不用说也会有桌面应用程序)。 我的技术技能相当实证,我的背景研究是艺术,但我确实经常使用编码。我问自己的主要问题是“我如何在移动设备,Web服务器(API或任何你想要调用的)和桌面应用程序之间获得无缝的体验?如何在事件发生时保持一致以及如何确保这个瞬间的表示在这个软件星座的不同层次上是相同的?

正如你可能知道使用移动设备编码意味着你正在使用SQLite数据库和Web应用程序,主要意味着MySQL。对于我所能想象到的最令人头疼的事情之一,我对使用时间数据从一张表到另一张表感到非常失望,可以选择什么?DateTime?Timestamp?哦,天哪,SQLite没有内置时间数据类型...... Unix时间?好吧,没问题,当然MySQL不会使用UNIX时间作为标准...会太简单...

我学到的是......如果你想把数据放在时间轴上,并说这是事件发生的时间轴上的时间点,那就使用时间戳(无论是UNIX还是MySQL的样式,也就是ISO8601)。人类可读性只是我的一个细节。没有人应该阅读数据库表,计算机,并且你确实告诉计算机处理数据,以便人类能够理解。但接下来是“什么是时区?”的问题弹出...呃...它很糟糕...但是,嘿,将挖掘网络的答案。

我自己我很惊讶,MySQL不使用UNIX时间,我认为这是最标准和一致的时间。

我真的认为围绕这​​个问题的文档更加轻松......我现在正在考虑编写一些关于如何处理MySQL和SQLite的文章。我在这件事上浪费了3天的时间,试图理解如何使它变得干净和简单。我的结论,与现有的文件,你只是不能...:PI很可能是错的......不管怎么说,看看这个视频显示的关于MySQL中的时间数据处理斗争: http://www.youtube.com/watch?v=fp-etlirjbo

感谢张贴这个问题,这对我来说很有启发。

干杯,

+2

始终使用UTC时区,每当你需要一个本地时间转换为本地时间。 – 2015-10-05 08:58:53

+1

@AnthonyHunt ....为什么? Unix时间是一个数字。 *该值总是GMT *这是一个很大较短(UNIX时间戳需要一个32位整数,而时间戳需要ASCII的200位) *它的平台/语言无关,并通过所有的编程语言 * 64位操作系统使用处理一个64位t_time整数,所以它会持续宇宙的热死亡 所以我真的很好奇,为什么你会选择牺牲移动性,大小和malь字符串解析? – Ancarius 2016-08-17 20:09:59