我知道这是一个非常常见的问题，但我觉得我找到的答案确实解决了问题。我将概述我的具体用例，并将摘要提供给其他SO答案和网络上的信息。
对于服务，我编写数据库条目是在移动设备和我们的网站上创建和存储的，需要同时进行同步。我们目前的目标是Android和iOS，它们都使用sqlite作为关系数据库。服务器端使用Django和MySQL在Python中实现，但其他解决方案可能在将来取代它。
将按照此SO答案中概述的想法实施同步：https://stackoverflow.com/a/5052208/2076094。对于同步，我们将使用仅由服务器设置并同步到客户端的时间戳，用于创建和更新对象的last_synced_date和时间戳。由于对象引用用户在某些时间所做的事情，因此它们也有时间戳信息。
我的问题仅涉及用于这些时间戳的内部时间表示。 UI中的用户表示是内部表示的本地化和格式化版本。在实现语言和用于表示时间戳的不同数据库中有许多不同的方式。经过相当多的研究后，似乎只剩下有效的解决方案了：
黑客新闻（两次）上的这个article建议使用UNIX时间并提出一个很好的论据。正如所预料的那样，关于HN的讨论在上述两点以及一些点之间存在很大差异。
到目前为止，我的结论是，Unix时间戳更容易处理，但似乎并不是Django的常用方法。几乎我发现的每个代码示例，从Django教程到很多其他站点，都使用models.py中的DateTimeField，它被映射到SQL中的某种日期字段，具体的术语取决于所使用的数据库。
使用ISO8601日期进行传输和存储的缺点是需要解析它们以创建相应的实现语言的日期类型。这并不难，但有点烦人。对于我们使用的每种语言，您需要一个（小）库或者至少需要比您希望的更多的代码。它不是很漂亮，会创建依赖关系并且可能会稍微慢一点。 Unix时间时间戳在我所知道的任何语言中都没有这个问题。
另一件事是你可以轻易地使用＆＃34; smart＆＃34;数据库中的日期或时间戳字段（以及解析期间）。关于时间魔法的问题有很多问题可以解决问题。达到了我的链接限制，因此我无法发布任何内容，但您很容易找到一些内容;）
我们可以使用不包含时区信息的简化格式，只使用UTC。我们只会使用UTC，但似乎如果你使用ISO8601，你也可以使用一种普遍理解和明确的格式。 Unix时间始终是UTC，所以你永远不必担心。
当然，当您查看原始数据库时，ISO8601具有人类可读的优势，并且我不必在2038年之前不久重写几行代码，但这似乎无法弥补缺点。
似乎通过写出来我实际上已经得到了我的答案;）无论如何，我很想知道别人的想法以及你在自己的项目中做了什么。请简要介绍一下您的用例，以便其他人可以更好地对您的输入进行分类。
谢谢！
答案 0 :(得分：1)
很难找到有关时间数据类型或时间标准格式的任何信息，无论它是什么。在过去的几天里，我一直在努力选择合适的时间格式。 就像你一样，我也在移动设备和网络服务器中进行编码（更不用说还会有桌面应用程序）。
我问自己的主要问题是“我怎样才能在移动设备，网络服务器（API，或者你想要的任何东西）和桌面应用程序之间获得无缝体验？你怎样才能在事件发生并且如何确保此瞬间的表示在此软件星座的不同级别中是相同的？
您可能知道使用移动设备编码意味着您使用的是SQLite数据库，而Web应用程序通常意味着MySQL。我非常失望地知道我能想象到的最令人头疼的问题之一就是从一个数据库转到另一个数据库。选择什么？约会时间？时间戳？哦天哪，SQLite没有内置时间数据类型... Unix时间？好的，没问题，当然MySQL不使用UNIX时间作为标准......太简单了......
我学到的是......如果您想将数据放在时间轴上并说这是此事件发生的时间轴上的点，最佳使用时间戳（无论是UNIX还是MySQL风格，又名ISO8601）。
人类可读对我来说只是一个细节。没有人应该阅读数据库表，计算机会这样做，并且您确实告诉计算机按照人类可以理解的顺序处理数据。
但是那么“什么是时区？”的问题弹出 ......嗯......糟透了......但是，嘿，会在网上挖掘答案。
我自己我很惊讶MySQL没有使用UNIX时间，我认为这是最标准和一致的时间格式。
我真的认为围绕这些选择的文档和标准是有限的 ......我现在正在考虑写一些关于如何处理MySQL和SQLite的时间。我在这个问题上确实浪费了一半的时间，试图理解如何使它干净简单，结论是，用你可用的文档你不能......
我可能错了......
无论如何，请看一下这段视频，展示了在MySQL中处理时间戳数据的困难：