mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Merge pull request #16796 from wxy/20191224-Unix-is-turning-50.-What-does-that-mean
TSL:20191224 Unix is turning 50. What does that mean
This commit is contained in:
Xingyu.Wang
GitHub
commit
1e963d1e18
@ -1,119 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Unix is turning 50. What does that mean?)
|
||||
[#]: via: (https://www.networkworld.com/article/3511428/unix-is-turning-50-what-does-that-mean.html)
|
||||
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
|
||||
|
||||
Unix is turning 50. What does that mean?
|
||||
======
|
||||
Unix time, also known as 'epoch time,' is the number of seconds that have passed since Jan 1, 1970. As Unix turns 50, let's take a look at what worries kernel developers.
|
||||
[cbaquiran][1] [(CC0)][2]
|
||||
|
||||
2020 is a significant year for Unix. At the very start of the year, Unix turns 50.
|
||||
|
||||
While some of the early development of Unix predates the official start of its "epoch," Jan 1, 1970 remains the zero-point in POSIX time and the recognized beginning of all things Unix. Jan 1, 2020 will mark 50 years since that moment.
|
||||
|
||||
### Unix time vs human time
|
||||
|
||||
In terms of human time, 50 years is a big deal. In terms of Unix time, there's nothing particularly special about 50 years. 48.7 years would be no less significant.
|
||||
|
||||
[][3]
|
||||
|
||||
BrandPost Sponsored by HPE
|
||||
|
||||
[Take the Intelligent Route with Consumption-Based Storage][3]
|
||||
|
||||
Combine the agility and economics of HPE storage with HPE GreenLake and run your IT department with efficiency.
|
||||
|
||||
Unix (including Linux) systems store date/time values as the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC in 32 bits. To determine how many seconds have passed since that time and, thus, what right now looks like as a Unix time value, you can issue a command like this:
|
||||
|
||||
```
|
||||
$ date +%s
|
||||
1576883876
|
||||
```
|
||||
|
||||
The **%s** argument tells the date command to display the current date/time as the number of seconds since the start of 1970-01-01.
|
||||
|
||||
### How much time can Unix systems manage?
|
||||
|
||||
To understand how much time Unix systems can accommodate, we need to look at the capacity of a 32-bit field. It can be calculated like this:
|
||||
|
||||
```
|
||||
$ echo '2^32' | bc
|
||||
4294967296
|
||||
```
|
||||
|
||||
However, since Unix needs to accommodate negative numbers, it reserves one bit for a number's sign, thus reducing this to:
|
||||
|
||||
```
|
||||
$ echo '2^31' | bc
|
||||
2147483648
|
||||
```
|
||||
|
||||
And, since Unix numbering begins with 0, that means we have 2,147,483,648 values, but the largest possible value is 2,147,483,647. Unix date/time values cannot exceed that number – just like the odometer on your car probably can't exceed 999,999 miles. Add 1 and the value turns to 0.
|
||||
|
||||
### How long is a year in seconds?
|
||||
|
||||
The number of seconds in most years can be calculated like this – hours/day multiplied by minutes/hour multiplied by seconds/minute multiplied by the number of days in a year:
|
||||
|
||||
```
|
||||
$ expr 24 \* 60 \* 60 \* 365
|
||||
31536000
|
||||
```
|
||||
|
||||
In leap years, we just add another day:
|
||||
|
||||
```
|
||||
$ expr 24 \* 60 \* 60 \* 366
|
||||
31622400
|
||||
```
|
||||
|
||||
### **How will Unix see its 50 year birthday?**
|
||||
|
||||
12:00 AM on Jan 1, 2020 will be **1577836800** in epoch time. The calculation is a little tricky, but mostly because we have to accommodate leap years. Since the start of the epoch, we've had 12 leap years, starting in 1972, the last in 2016. And, when we reach 2020, we will have had 38 regular years.
|
||||
|
||||
Here’s a calculation using the **expr** command to count the seconds in these 50 years:
|
||||
|
||||
```
|
||||
$ expr 24 \* 60 \* 60 \* 365 \* 38 + 24 \* 60 \* 60 \* 366 \* 12
|
||||
1577836800
|
||||
```
|
||||
|
||||
The first half of that is calculating the seconds in the 38 non-leap years. We then add a similar calculation for leap years with their 366 days. Conversely, you could use the seconds per year figures presented earlier and just do this:
|
||||
|
||||
```
|
||||
$ expr 31536000 \* 38 + 31622400 \* 12
|
||||
1577836800
|
||||
```
|
||||
|
||||
This way of tracking dates and times made Unix systems fairly impervious to the Y2K scare that had people in late 1999 worried that moving into the year 2000 would wreak havoc on computer systems. Far fewer problems were experienced than people feared. In fact, only applications which stored years in a two-digit format would see the year going to 00 as a sign that time jumping backwards. Still, lots of application developers had some tedious extra work piled onto their plates to ensure that their systems wouldn’t run into serious problems when 2000 hit.
|
||||
|
||||
### When Unix time will run into problems
|
||||
|
||||
Unix systems won’t run into a **Y2K** type of problem until **2038** when dates stored as described above will overrun their 32-bit space allotments. But that’s 18 years from now, and kernel developers are already working on how they will avert disaster. It’s a bit too early to start panicking.
|
||||
|
||||
The year 2038 problem is sometimes referred to as the **Y2K38** problem. We have until Tuesday, January 19, 2038 to address it. If the problem isn’t resolved, systems after that date may think it’s 1901. One way to address the problem would be to switch to 64-bit representations of date/time information. Some people believe that even that will be a lot more complex than it sounds. In any case, it’s probably still too early to panic. And, in the meantime, maybe after singing "Auld Lang Syne" this New Year’s Eve, you can sing "Happy Birthday" to Unix. It’s turning 50, and that’s still a very big deal.
|
||||
|
||||
Join the Network World communities on [Facebook][4] and [LinkedIn][5] to comment on topics that are top of mind.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3511428/unix-is-turning-50-what-does-that-mean.html
|
||||
|
||||
作者：[Sandra Henry-Stocker][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.networkworld.com/author/Sandra-Henry_Stocker/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://pixabay.com/en/birthday-cake-cake-birthday-380178/
|
||||
[2]: https://creativecommons.org/publicdomain/zero/1.0/
|
||||
[3]: https://www.networkworld.com/article/3440100/take-the-intelligent-route-with-consumption-based-storage.html?utm_source=IDG&utm_medium=promotions&utm_campaign=HPE20773&utm_content=sidebar ( Take the Intelligent Route with Consumption-Based Storage)
|
||||
[4]: https://www.facebook.com/NetworkWorld/
|
||||
[5]: https://www.linkedin.com/company/network-world
|
||||
@ -0,0 +1,111 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Unix is turning 50. What does that mean?)
|
||||
[#]: via: (https://www.networkworld.com/article/3511428/unix-is-turning-50-what-does-that-mean.html)
|
||||
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
|
||||
|
||||
Unix 即将迎来 50 岁
|
||||
======
|
||||
|
||||
Unix 时间（又称为“<ruby>纪元时间<rt>epoch time</rt></ruby>”）是自 1970 年 1 月 1 日以来经过的秒数。当 Unix 即将 50 岁时，让我们看一下让内核开发人员担心的地方。
|
||||
|
||||
[cbaquiran][1]
|
||||
|
||||
对于 Unix 而言，2020 年是重要的一年。在这一年年初，Unix 进入 50 岁。
|
||||
|
||||
尽管 Unix 的某些早期开发早于其“纪元”的正式开始，但 1970 年 1 月 1 日仍然是 POSIX 时间的零点，也是公认的 Unix 的万物之始。自那一刻算起，2020 年 1 月 1 日将是其 50 周年。
|
||||
|
||||
### Unix 时间与人类时间
|
||||
|
||||
就人类时间而言，50 年是很重要的。就 Unix 时间而言，50 年没有什么特别的。48.7 年同样重要。
|
||||
|
||||
Unix（包括 Linux）系统将日期/时间值存储为自 1970-01-01 00:00:00 UTC 以来经过的秒数（32 位二进制）。要确定自该时间以来经过了几秒钟，看看 Unix 时间值是什么样子，你可以发出如下命令：
|
||||
|
||||
```
|
||||
$ date +%s
|
||||
1576883876
|
||||
```
|
||||
|
||||
`％s` 参数告诉 `date` 命令将当前日期/时间显示为自 1970-01-01 开始以来的秒数。
|
||||
|
||||
### Unix 系统可以管理多少时间？
|
||||
|
||||
要了解 Unix 系统可以容纳多少时间，我们需要查看 32 位字段的容量。可以这样计算：
|
||||
|
||||
```
|
||||
$ echo '2^32' | bc
|
||||
4294967296
|
||||
```
|
||||
|
||||
但是，由于 Unix 需要容纳负数，因此它会为数字的符号保留一位，从而将其减少为：
|
||||
|
||||
```
|
||||
$ echo '2^31' | bc
|
||||
2147483648
|
||||
```
|
||||
|
||||
并且，由于 Unix 计数以 0 开头，这意味着我们有 2,147,483,648 个值，但最大的可能值为 2,147,483,647 个。Unix 日期/时间值不能超过该数字——就像汽车上的里程表可能不能超过 999,999 英里一样。加 1 该值就变为了 -2147483648。（LCTT 译注：此处原文描述有误，已修改。在达到最大值之后，即 2018/1/19 03:14:07，下 1 秒导致符号位变为 1，其余 31 位为 0，即 -2147483648，时间变为 1901/12/13 20:45:52，这就是 Y2K38 问题。）
|
||||
|
||||
### 一年有多少秒？
|
||||
|
||||
大多数年份的秒数可以这样计算：每天的小时数乘以每小时的分钟数乘以每分钟的秒数乘以一年中的天数：
|
||||
|
||||
```
|
||||
$ expr 24 \* 60 \* 60 \* 365
|
||||
31536000
|
||||
```
|
||||
|
||||
在闰年，我们再增加一天：
|
||||
|
||||
```
|
||||
$ expr 24 \* 60 \* 60 \* 366
|
||||
31622400
|
||||
```
|
||||
|
||||
### Unix 将如何庆祝其 50 岁生日？
|
||||
|
||||
2020 年 1 月 1 日中午 12:00 是纪元时间的 1577836800。这个计算有些棘手，但主要是因为我们必须适应闰年。自该纪元开始以来，我们经历了 12 个闰年，从 1972 年开始，到上一个闰年是 2016 年。而且，当我们达到 2020 年时，我们将有 38 个常规年份。
|
||||
|
||||
这是使用 `expr` 命令进行的计算，以计算这 50 年的秒数：
|
||||
|
||||
```
|
||||
$ expr 24 \* 60 \* 60 \* 365 \* 38 + 24 \* 60 \* 60 \* 366 \* 12
|
||||
1577836800
|
||||
```
|
||||
|
||||
前半部分是计算 38 个非闰年的秒数。然后，我们加上闰年的 366 天的类似计算。或者，你可以使用前面介绍的每年秒数，然后执行以下操作：
|
||||
|
||||
```
|
||||
$ expr 31536000 \* 38 + 31622400 \* 12
|
||||
1577836800
|
||||
```
|
||||
|
||||
这种跟踪日期和时间的方式使 Unix 系统完全不受 Y2K 恐慌的影响，1999 年末人们开始担心进入 2000 年会对计算机系统造成严重破坏。但是实际遇到的问题比人们担心的少得多。实际上，只有以两位数格式存储年份的应用程序才会将年份变为 00，以表示时间倒退。尽管如此，许多应用程序开发人员还是做了很多额外的繁琐工作，以确保 2000 年到来时，他们的系统不会出现严重问题。
|
||||
|
||||
### Unix 时间何时会遇到问题？
|
||||
|
||||
在 2038 年之前，Unix 系统不会遇到 Y2K 类型的问题，直到如上所述存储的日期将超过其 32 位空间分配。但这距离现在已经只有 18 年了，内核开发人员已经在研究如何避免灾难。但现在开始恐慌还为时过早。
|
||||
|
||||
2038 年的问题有时称为 Y2K38 问题。我们必须在 2038 年 1 月 19 日星期二之前解决这个问题。如果问题到时候仍未解决，则该日期之后的系统可能会认为是 1901 年。解决该问题的一种方法是切换为日期/时间信息的 64 位表示形式。有些人认为，即使那样，也会有比听起来更复杂的问题。无论如何，恐慌还为时过早。并且，与此同时，也许在新年前夜演唱了《Auld Lang Syne》之后，你可以向 Unix 唱《生日快乐》歌了。Unix 50 岁了，这仍然是大事。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3511428/unix-is-turning-50-what-does-that-mean.html
|
||||
|
||||
作者：[Sandra Henry-Stocker][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.networkworld.com/author/Sandra-Henry_Stocker/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://images.idgesg.net/images/article/2017/10/birthday-cake-candles-100739452-large.jpg
|
||||
[2]: https://creativecommons.org/publicdomain/zero/1.0/
|
||||
[3]: https://www.networkworld.com/article/3440100/take-the-intelligent-route-with-consumption-based-storage.html?utm_source=IDG&utm_medium=promotions&utm_campaign=HPE20773&utm_content=sidebar ( Take the Intelligent Route with Consumption-Based Storage)
|
||||
[4]: https://www.facebook.com/NetworkWorld/
|
||||
[5]: https://www.linkedin.com/company/network-world
|
||||
Loading…
Reference in New Issue
Block a user