我们知道在Java中System.currentTimeMillis()方法来获取系统当前时间与1970年1月1日0点之间的毫秒差距。而在.NET中也有System.Environment.TickCount()方法来获取与1970年1月1日0点之间的毫秒差距，这个1970.01.01
00:00:00就是系统的最小时间，那么为什么系统的最小时间是这个，而不是0001.01.01 00:00:00呢？
这个还是要从计算机的构造说起，可以追溯到Unix操作系统。UNIX系统认为1970年1月1日0点是时间纪元，所以我们常说的UNIX时间戳是以1970年1月1日0点为计时起点时间的。
计算机是怎么计时间的呢？设定一个时间的最小值，然后设置一个变量，每过一秒，这个变量就加1.所以当前时间就是最小时间与变量的和。最初计算机操作系统是32位，而时间也是用32位表示。32位能表示的最大值是2147483647。另外1年365天的总秒数是31536000，2147483647/31536000=
68.1，也就是说32位能表示的最长时间是68年，也就是说，以当时的计算机水平，能够记住的时间最多是68年，因为那个变量最多能够存那么多秒数。那时候20世纪中后期，那时候人们就需要制定时间的最小值啊。总不能是0001年吧，那即使加上68年也远远没到那会的时间啊。最终综合考量，决定把1970年1月1日0点定位最小值。因为那时候32位系统足以解决那个年头的计数问题。
现在我们思考，如果是1970年是最小年头，32位系统的话，那么到了2038年01月19日03时14分07秒（这个就是32位能够记住的最大的数），时间还是会回归到最小值。
上边说过了，那时候是七八十年代，已经足以解决当时的问题了。他们想，2038年出现问题，就让那时候的后代去解决吧。事实上他们是对的，因为现在我们已经解决了这个问题，就是64位系统，因为用64位操作系统可以表示到292,277,026,596年12月4日15时30分08秒，相信我们的N代子孙，哪怕地球毁灭那天都不用愁不够用了，因为这个时间已经是千亿年以后了。
正如中国政府对南海问题持有的态度，让后代去解决吧，我们把眼前的事情解决了就行，搁置争议，共同开发。