为什么日期是从1970年1月1日算起的？

Question

使用日期(1970年1月1日)作为时间操纵的默认标准是否有任何理由？我在Java和Python中都看到过这个标准.我知道这两种语言.是否有其他流行语言遵循相同的标准？

请描述一下.

Answer 1

该课题有两个错误的假设:

• 计算中的所有时间跟踪都是自1970年以来的计数.
• 这种跟踪是标准的.

二十几个时代

从UTC 1970年开始,并不总是跟踪计算时间.虽然那个时代很受欢迎,但几十年来各种计算环境至少使用了二十几个时代.有些来自其他世纪.它们的范围从0年(零)到2001年.

这里有几个.

公元前1月0日

公元1月1日

1582年10月15日

1601年1月1日

1840年12月31日

1858年11月17日

1899年12月30日

1899年12月31日

1900年1月1日

1904年1月1日

1967年12月31日

1980年1月1日

1980年1月6日

2000年1月1日

2001年1月1日

Unix Epoch Common,但不是主导

1970年初很受欢迎,可能是因为Unix使用它.但绝不是占主导地位.例如:

• 数以百万计(数十亿？)的Microsoft Excel和Lotus 1-2-3文档使用January 0, 1900(1899年12月31日).
• 现在世界上有超过十亿个使用Cocoa(NSDate)时代的iOS/OS X设备1 January 2001, GMT.
• 在GPS卫星导航系统使用January 6, 1980而欧洲替代伽利略使用22 August 1999.

ISO 8601

假设count-since-epoch正在使用Unix时代正在为bug打开一个大漏洞.这样的计数对于人类来说不可能立即解密,因此在调试和记录时不会轻易地标记错误或问题.另一个问题是下面解释的粒度的模糊性.

我强烈建议将日期时间值序列化为数据交换的明确ISO 8601字符串,而不是整数count-since-epoch:YYYY-MM-DDTHH:MM:SS.SSSZ例如2014-10-14T16:32:41.018Z.

算什么,自纪元

count-since-epoch时间跟踪的另一个问题是时间单位,通常使用至少四个级别的分辨率.

• 秒如果存储为32位整数
  ,则原始Unix工具使用整秒,导致2038年问题达到自1970年以来的秒数限制.
• 毫秒
  由较旧的Java库使用,包括捆绑的java.util.Date类和Joda-Time库.
• 微秒数
  由Postgres等数据库使用.
• 纳秒
  由Java 8中的新java.time包使用.

Answer 2

这是Unix时间的标准.

Unix时间或POSIX时间是用于描述时间点的系统,定义为自1970年1月1日午夜无效协调世界时(UTC)以来经过的秒数,不计算闰秒.

Answer 3

使用日期（1970 年 1 月 1 日）作为时间操作的标准有什么原因吗？

没有理由那么重要。

Python 的time模块是C 库。问问肯·汤普森，他为什么选择那个日期作为划时代的日期。也许是某人的生日。

Excel 使用两个不同的时代。为什么不同版本的excel使用不同的日期？

除了真正的程序员，没有人会知道为什么做出这些决定。

和...

为什么选择日期并不重要。它只是。

天文学家使用自己的划时代日期：http : //en.wikipedia.org/wiki/Epoch_( astronomy )

为什么？必须选择一个日期才能计算出结果。任何随机日期都可以。

对于一般情况，过去的日期避免了负数。

一些更智能的包使用预测的格里高利年 1。有什么理由为什么是第 1 年？
像日历计算这样的书中给出了一个原因：它在数学上稍微简单一些。

但是如果你仔细想想，1/1/1 和 1/1/1970 之间的区别只是 1969 年，一个微不足道的数学偏移。

Answer 4

为什么它总是 1st jan 1970 ，因为 - '1st January 1970' 通常称为“纪元日期”是 Unix 计算机的时间开始日期，并且该时间戳记标记为“0”。自该日期以来的任何时间都是根据经过的秒数计算的。简而言之......任何日期的时间戳将是该日期与“1970 年 1 月 1 日”之间的秒数差异时间戳只是一个整数，它从“1970 年 1 月 1 日午夜”的数字“0”开始并继续递增by '1' as each second pass 用于将 UNIX 时间戳转换为可读日期 PHP 和其他开源语言提供了内置函数。

Answer 5

1970年1月1日00:00:00 am是POSIX时间的零点.