这个问题在这里已经有答案了：
为什么1970年1月1日是；大纪元；？
（五个答案）
（五个答案）
9个月前关闭
使用日期（1970年1月1日）作为时间操纵的默认标准有什么原因吗？我在Java和Python中都看到了这个标准。我知道这两种语言。还有其他流行语言遵循相同的标准吗
请描述一下
使用日期（1970年1月1日）作为默认标准
这个问题有两个错误的假设：
- 自1970年以来，计算机中的所有时间跟踪都是作为计数进行的
- 这种跟踪是标准的
二十年
计算时间并非总是从1970 UTC开始跟踪。虽然那个时代的参考很流行，但几十年来各种计算环境至少使用了二十多个时代。有些来自其他世纪。其范围从0年（零）到2001年
这里有一些
公元前1年1月0日
公元1年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日
二○○○年一月一日
二○○一年一月一日
Unix时代很普遍，但不占主导地位
1970年初很流行，可能是因为Unix使用了它。但这绝不是占主导地位。例如：
- 数以百万计（数十亿？）的微软Excel&；Lotus 1-2-3文档使用的是1900年1月0日（1899年12月31日）
- 现在世界上有超过10亿台iOS/OSX设备使用2001年1月1日格林尼治标准时间的Cocoa（NSDate）时代
- GPS卫星导航系统使用1980年1月6日的
ISO 8601
假设自epoch使用Unix epoch以来有一个计数，则会为bug打开一个很大的漏洞。这样的计数对于人类来说是不可能立即破译的，所以在调试和记录时，错误或问题不会很容易被标记出来。另一个问题是下面解释的粒度的模糊性
我强烈建议将日期时间值序列化为明确的ISO 8601字符串，用于数据交换，而不是从epoch开始的整数计数：YYYY-MM-DDTHH:MM:SS.SSSZ，例如2014-10-14T16:32:41.018Z
从新纪元开始的什么的计数
自历元时间跟踪以来计数的另一个问题是时间单位，通常使用至少四个级别的分辨率
- 秒
最初的Unix工具使用整秒，如果存储为32位整数，则会导致2038年的问题，即自1970年以来达到秒数限制 - 毫秒
由旧的Java库使用，包括捆绑的Java.util.Date类和Joda时间库 - 微秒
由数据库（如Postgres）使用 - java 8中新的java.time包使用的纳秒