Unix 时间（又称为“ 纪元时间(epoch time)”）是自 1970 年 1 月 1 日以来经过的秒数。当 Unix 即将 50 岁时，让我们看一下让内核开发人员担心的地方。
尽管 Unix 的某些早期开发早于其“纪元”的正式开始，但 1970 年 1 月 1 日仍然是 POSIX 时间的零点，也是公认的 Unix 的万物之始。自那一刻算起，2020 年 1 月 1 日将是其 50 周年。（LCTT 译注：实际上，在 1971/11/3 出版的第一版《Unix 程序员手册》中，将 1971/1/1 作为 Unix 纪元的开始，并且一秒钟记录 60 个数，但是后来发现这样 32 位整型数字只能记录两年多，后来这个纪元被一再重新定义，改为从 1970/1/1 开始，每秒 1 个数。）
就人类时间而言，50 年是很重要的。就 Unix 时间而言，50 年没有什么特别的。48.7 年同样重要。
Unix（包括 Linux）系统将日期/时间值存储为自 1970-01-01 00:00:00 UTC 以来经过的秒数（32 位整型）。要确定自该时间以来经过了多少秒钟，看看 Unix 时间值是什么样子，你可以发出如下命令：
％s 参数告诉 date 命令将当前日期/时间显示为自 1970-01-01 开始以来的秒数。
大多数年份的秒数可以这样计算：每天的小时数乘以每小时的分钟数乘以每分钟的秒数乘以一年中的天数：
前半部分是计算 38 个非闰年的秒数。然后，我们加上闰年的 366 天的类似计算。或者，你可以使用前面介绍的每年秒数，然后执行以下操作：
这种跟踪日期和时间的方式使 Unix 系统完全不受 Y2K 恐慌的影响，1999 年末人们开始担心进入 2000 年会对计算机系统造成严重破坏，但是实际遇到的问题比人们担心的少得多。实际上，只有以两位数格式存储年份的应用程序才会将年份变为 00，以表示时间倒退。尽管如此，许多应用程序开发人员还是做了很多额外的繁琐工作，以确保 2000 年到来时，他们的系统不会出现严重问题。
在 2038 年之前，Unix 系统不会遇到 Y2K 类型的问题，直到如上所述存储的日期将超过其 32 位空间分配。但这距离现在已经只有 18 年了，内核开发人员已经在研究如何避免灾难。但现在开始恐慌还为时过早。
2038 年的问题有时称为 Y2K38 问题。我们必须在 2038 年 1 月 19 日星期二之前解决这个问题。如果问题到时候仍未解决，则该日期之后的系统可能会认为是 1901 年。解决该问题的一种方法是切换为日期/时间信息的 64 位表示形式。有些人认为，即使那样，也会有比听起来更复杂的问题。无论如何，恐慌还为时过早。并且，与此同时，也许在新年前夜演唱了《Auld Lang Syne》之后，你可以向 Unix 唱《生日快乐》歌了。Unix 50 岁了，这仍然是大事。
（LCTT 译注：建议阅读一下 Unix 时间的 维基百科 页面，有更多有趣和不为人知的信息。）
