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