我应该如何保持服务器时间？答案

【问题标题】：How should I keep server time?我应该如何保持服务器时间？
【发布时间】：2013-08-22 10:55:34
【问题描述】：

我看到人们使用 date 或 getTime 存储/获取服务器时间和相对于它的时间，这些时间可以作为字符串保存在数据库中：“July 21, 1983 01:15:00”。

到目前为止，我将服务器时间存储为 NOW 和 2013 年 1 月 1 日之间的差值。这将返回一个数值（以分钟为单位），在 2013 年 1 月 1 日和现在之间四舍五入，我将其保留为内部服务器时间。

这样做的好处是： - 查询服务器意味着一个简单的数字比较操作，而（我做出有根据的猜测）比较两个日期意味着内部转换为对象并使用胖比较操作。 - 存储该大小的数字比约 25 个字符的字符串更轻量。 - 转换回“实时”时间是通过添加 2013 年 1 月 1 日，但由于初始圆度，秒和毫秒值会丢失。

但是，其他程序员仍然坚持使用字符串版本 - 作为人类很容易阅读。 - 它是大多数语言的通用格式（尤其是本项目拥有的 nodejs、mongodb 和 as3）。

我不确定哪个更适合大型数据库，特别是基于多人套接字的游戏。我相信在这方面有实际经验的其他人可以对我的问题有所了解。

那么哪个更好，为什么？

【问题讨论】：

也将它们存储为 UTC 并使您的应用程序具有 tz 意识，这样您就拥有真正的国际化。我真的会与您一直在与之交谈的程序员争论...数据库存储的数据不应该是人类可读的，这就是您制作应用程序的原因
那么为什么不将它们存储为 2013 年 1 月 1 日之间的差异呢？这样两个日期都在同一个时区。事实上，所有差异都在同一时区日期之间。
@Discipol 如果您将它们存储为 int 并且它们将是未来的证明，那么没有任何反对该部分的内容，但是任何其他需要更高分辨率的日期都应该是 datetime 对象，字符串日期是丧钟，我接管的许多系统都犯了这些错误......
我可能表达错误，混杂着无知。我当然将存储在服务器中作为 mongodb 日期：|我只是认为差异版本在比较中会占用更少的速度/更快：|我无法理解我的不同想法是否面向未来/有效，但您似乎已经处理了大型服务器的份额。
哦，好的，是的，差异版本会占用更少的空间。我也应该让自己更清楚，数据库端的未来校对很好，你需要确保在你的应用程序中你永远不会因此而受苦。当您的应用程序已经使用了几年甚至几十年，并且您需要执行高级日期聚合功能时，您可能会遇到这种情况，这是一个完整的日期对象可能更有益的地方

【解决方案1】：

将它们存储为 Mongo Date 对象。 Mongo 将日期存储为 8 字节秒偏移整数 [1]，并以人类可读的格式显示它们。您没有存储 25 个字符！

因此，所有比较都一样快。除了查询时，没有字符串解析，这是每次查询的一次性操作。

您的差异存储为 4 个字节的 int。因此，与普通的 MongoDB 日期存储相比，您只节省了 4 个字节。考虑到 mongo 对象的平均大小，这是一个非常小的节省。

考虑“自 2013 年 1 月以来的抵消”方法的所有缺点：

基本上，更多的代码和更多的头痛和花费更多的时间，所有这些都是为了在数据库中的对象上保存 4 个字节，而通过将字段从“updated”重命名为“upd”可以保存相同的 4 个字节？我不认为这是一个明智的权衡。

过早的优化是万恶之源。除非您确定某事存在问题，否则不要进行优化。

【讨论】：