关于unix：为什么1970年1月1日是“纪元时代”？

Why is 1/1/1970 the “epoch time”?

为什么是

1 January 1970 00:00:00

号

考虑了时代？

相关讨论

早期版本的Unix以1/60 s的间隔测量系统时间。这意味着32位无符号整数只能表示小于829天的时间跨度。因此，用数字0表示的时间(称为epoch)必须在最近的过去设定。正如20世纪70年代初一样，这个时代被设定为1971-1-1。

后来，系统时间被更改为每秒钟递增，从而将32位无符号整数表示的时间跨度增加到大约136年。由于挤出每秒钟的时间不再那么重要，这个时代被四舍五入到最近的十年，因此变成了1970-1-1。我们必须假设这被认为比1971-1-1更整洁。

请注意，使用1970-1-1作为其历元的32位有符号整数可以表示到2038-1-19的日期，在该日期它将环绕到1901-12-13。

相关讨论

1/60和美国电网的频率有关系吗？
它是当时系统板上一个振荡器的频率。由于振荡器是在直流电上运行的，所以它不必是60Hz的，但使用当时最常见的东西可能很便宜，那时电视正在大量生产……
实际上，在当时，计算机时钟和实时时钟与美国电源波形同步是很常见的，因为它是(是？)。非常可靠。它被乘以得到处理器时钟，再除以得到实时时钟的秒数。
@马托威尔斯-他们为什么不把新纪元升级到2000年？
@黑手党：对，我会在我的笔记本电脑上设置一个2038年的提醒…1901年12月13日。
@JedikNight-更新的语言，如fantom do！从他们的日期时间类："Fantom时间自2000年1月1日起标准化为纳秒刻度"
@JedikNight这是基于我作为一名开发人员的经验的推测：改变一个标准需要时间，如果你的改变不起作用，那么你最终会得到竞争的标准。epoch问题的真正解决方案是64位整数，而不是及时向前移动epoch。
@马特·豪威尔斯，你能给我这个官方标准的网址吗？
@更不用说杰迪克奈特，没有什么理由改变时代。当然，您可以节省一些额外的字节，但是最终用户会注意到甚至关心吗？另外，如果确实更改了epoch时间，那么依赖于时间戳的每个程序和库都必须更新到1970年的时间。
@杰迪克奈特，否则如果是0000-1-1…除了在1公元前到1公元前没有0年，或者可能是大爆炸的时候…除非我们只知道那是什么时候&2100万年，我们可能会溢出一些整数。所以，也许我们开发计算机的十年是可以的。
我期待在遥远的将来，地球人会相信宇宙是在1970年1月1日00:00:00创造的。
> ...a 32-bit signed integer ...will wrap around to 1901-12-13."我是否遗漏了一些东西，这不是整数溢出，因此在技术上没有定义(或者更实际地说，依赖于平台)？2038年维基百科上的问题与@matthowells > Times beyond that will"wrap around" and be stored internally as a negative number, which these systems will interpret as having occurred on 13 December 1901 rather than 19 January 2038.的想法一致？
@杰迪克奈特为什么不把新纪元改为明天呢？
@迈克尔，它将打破现有的许多系统
@对，但Jn问他们为什么不把时代升级到2000年…如果你要升级和打破东西，为什么不让它更接近今天，这样至少它会持续更长时间？
@Michael我认为还有更好的解决方案，将epoch升级到2000意味着我们的研究生孩子将面临同样的问题，我宁愿使用64位time-t和更新旧的32位系统来处理64位time-refer:en.wikipedia.org/wiki/year_problem
我认为人们忘记更新它的最大的事情，不仅是它代表"现在"，而且它存储在数据库、文件等中，所有这些都必须修复，这实际上是最糟糕的想法，而不是把它改成字母(开玩笑地)。这就是为什么唯一的选择是让它作为黑客不签名，或者最好给它64位的工作空间。与编辑数兆字节的数据相比，更改它更容易。
下面由@j&246；rg w mittag撰写的评论[stackoverflow.com/questions/1090869/&hellip；还提到了发展年是决定的一个因素。
时代的定义总是让我觉得自己是对的，但自从我在1970年出生几天以后，也许我有偏见(显然是几天)。

历史。

The earliest versions of Unix time had
a 32-bit integer incrementing at a
rate of 60 Hz, which was the rate of
the system clock on the hardware of
the early Unix systems. The value 60
Hz still appears in some software
interfaces as a result. The epoch also
differed from the current value. The
first edition Unix Programmer's Manual
dated November 3, 1971 defines the
Unix time as"the time since 00:00:00,
Jan. 1, 1971, measured in sixtieths of
a second".

号

相关讨论

http://en.wikipedia.org/wiki/unix-time history解释了一些关于unix时间和所选时代的起源。Unix时间和纪元日期的定义在稳定其现状之前经历了一些变化。

但这并不能说明为什么最终选择了1/1/1970。

维基百科页面的重要摘录：

The first edition Unix Programmer's Manual dated November 3, 1971 defines the Unix time as"the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second".

Because of [the] limited range, the epoch was redefined more than once, before the rate was changed to 1 Hz and the epoch was set to its present value.

Several later problems, including the complexity of the present definition, result from Unix time having been defined gradually by usage rather than fully defined to start with.

号

纪元参考日期

纪元参考日期是时间线上我们计算时间的点。在此点之前的时刻用负数计数，之后的时刻用正数计数。

很多时代都在使用

Why is 1 January 1970 00:00:00 considered the epoch time?

号

不，不是时代，是时代。有许多时代在使用。

这个时代的选择是任意的。

主要的计算机系统和图书馆使用至少几十个不同时代中的任何一个。其中一个最流行的时代通常被称为Unix时间，使用您提到的1970年UTC时刻。

虽然很流行，但unix-time的1970可能不是最常见的。同样，最常见的例子是1900年1月0日的无数Microsoft Excel&Lotus 1-2-3电子表格，或者2001年1月1日的苹果Cocoa框架在全球数十亿台iOS/MacOS机器上的无数应用程序中使用。或者可能是1980年1月6日被GPS设备使用？

许多颗粒

不同的系统在计数时间上使用不同的粒度。

甚至所谓的"unix时间"也会有所不同，有些系统会计算整秒数，有些则计算毫秒数。许多数据库(如Postgres)使用微秒。一些，比如Java 8和以后的现代JavaTimeFrand，使用纳秒。有些还使用其他粒度。

ISO 8601标准

因为在使用一个时代参考和粒度上有很大的差异，所以一般最好避免将时间作为一个时代的计数来传递。在不明确的时代和粒度之间，加上人类无法感知有意义的值(因此错过了错误的值)，使用纯文本而不是数字。

ISO 8601标准提供了一套实用的、精心设计的格式，用于将日期时间值表示为文本。这些格式很容易被机器解析，也容易被跨文化的人类阅读。

其中包括：

仅限日期：2019-01-23。
UTC时刻：2019-01-23T12:34:56.123456Z
偏离UTC的力矩：2019-01-23T18:04:56.123456+05:30。
以周为单位的年份：2019-W23
序日(1日至366日)：2019-234。

简短回答：为什么不呢？

更长的答案：时间本身并不重要，只要使用它的每个人都同意它的价值。由于1/1/70已经使用了很长时间，使用它将使尽可能多的人都能理解您的代码。

选择一个任意的时代只是为了与众不同没有什么大的价值。

相关讨论