Question

我最近开始研究一个新的应用程序，我需要能够比较用户活跃的时间，所以基本上我的逻辑将是这样的：

func pseudo (user string) {
    v := GET Timestamp FROM users;

    if currentTimestamp - 1800 < dbTimestamp
        // Do something

我虽然使用的是Unix时间戳，具体是秒数。但是我不确定存储这个是否会成为一个问题，因为它只会增长，我意识到需要一段时间才能添加更多的数字而不是因为性能原因而感觉它是最好的。存储和比较Unix时间戳是长期应用的好主意吗？

旁注：

我的应用程序是这样编写的，当我可以存储日期时，我必须从数据库中提取日期时间并尝试使用残酷的布局编号，并且尝试格式化以使用布局编号变得更加复杂。 / p>

Answer 1

一年有31,536,000秒，因此在将另一个数字添加到unix时间戳之前需要超过269年。

(10,000,000,000 - 1,510,798,414) / 31,536,000 = 269.1908

所以，按照这个数字我会说你好一段时间。

根据您使用的数据库列类型，更直接的问题可能是从2038年1月19日开始，您将无法再将时间戳存储在带符号的32位整数中，因为它们具有最大值2,147,483,647。

所以，我要说：在显示器上放一个便利贴，以便在2038年1月18日更改数据库列类型。如果你使用的是无符号32位整数类型，那么你就是这样做的。好到2106年。

Answer 2

我猜比特数不是一个大问题 - 长时间64位就足够了，以至于今天所有计算机行业都将完全过时。

但是有更严重的担忧。时间不是那么简单和线性。有时你有闰秒，这会打破正常的流量。时区也有时会发生变化。因此，存储和使用时间作为int你必须处理所有奇怪的问题。我绝对建议在数据库中切换特殊数据类型，以便在应用程序中使用。

我一直在使用秒数来存储日期。自从我使用MySQL 3.x和4.x以来，这是我的习惯 - 他们对日期的支持非常糟糕，所以在应用程序中实现它更容易，只保留整数值。但正如我所说，我必须经历其他问题，这不是太难，但需要时间和容易出错。如果在项目开始时你只需要保留一段时间，以后你需要计算间隔，然后用本地选项等等。

所以我建议使用特殊日期时间。 Go具有良好的精度，最大日期为219248499-12-06 - 足够我们:)。在PostgreSQL最大年份294276 AD。

从长远来看存储Unix时间戳是个坏主意

2 个答案: