haibian 于 2009-05-25 17:28:01发表:
纯属炒作
kpshare 于 2009-05-25 13:26:06发表:
好像不会。
紫色葡萄 于 2009-05-25 11:41:36发表:
干脆全世界约定，把2000年后归零，2001年就是01年，1999年就用上世纪99年来标识，这在计算机技术上肯定能实现，只是约定的问题。
jagub 于 2009-05-25 11:23:52发表:
好深奥的八卦新闻
me26659408 于 2009-05-25 07:55:10发表:
我现在都在用64位的了。。。 觉得非常好用。。。
f0rrest 于 2009-05-24 23:41:24发表:
2038年的时候，64位系统应该普及了。
yijunziran 于 2009-05-24 21:54:25发表:
随着社会的发展,这样的问题应该可以解决的吧
LinuxSpace 于 2009-05-24 21:36:03发表:
难道到时候就不能解决此问题了吗？？？
jyz19880823 于 2009-05-24 21:23:07发表:
<转来的> 1234567890是个节日, 一秒钟的节日. 它不是问题, 不是错误, 不是BUG. 我们人类使用的计时 系统是相当复杂的：秒是基本单位, 60秒为1分钟, 60分钟为1小时, 24小时是一天......如果计算机也使用相同的方式来计时, 那显然就要用多个变量来分别存放年月日时分秒, 不停的进行进位运算, 而且还要处理偶尔的闰年和闰秒以及协调不同的时区. 基于"追求简单"的设计理念, UNIX在内部采用了一种最简单的计时方式： 计算从 UNIX诞生[注释1]的UTC时间1970年 1月1日0时0分0秒起, 流逝的秒数. UTC时间1970年1月1日0时0分0秒就是UNIX时间0, UTC时间1970年1月2日0时0分0秒就是UNIX时间86400. 这个计时系统被所有的UNIX和UNIX-like系统继承了下来, 而且影响了许多非UNIX系统. POSIX标准推出后, 这个时间也被称为POSIX时间. - 节日和庆祝 - 可能是因为人类是一种需要精神上的刺激的生物吧, 各种历法中都存在着各种拥有不同意义的节日. 其中, 很多节日仅仅由于日期的特殊性就被赋予了意义, 例如公历1月1日的新年, 11月11日的光棍节... 爱好节日的人们也没有放过UNIX时间. UTC时间2001年9月9日1时46分40秒, UNIX时间迎来了第一个"亿禧年"(Billennium)[注释2], 1000000000. UTC时间2005年3月18日1时58分31秒则是UNIX时间的光棍节, 1111111111. 刚刚过去的1234567890, 对应公历的UTC2009年2月13日23时31分30秒, 对东一区以东的时区来说是2月14日情人节, 以西的时区来说则刚好落在黑色星期五. 传统上认为黑色星五不吉利的西方媒体, 针对此事进行了玩笑性的报道, 结果被一些居住在其他时区的人们误读成了"UNIX时间错误". 丹麦哥本哈根的丹麦UNIX用户群组织庆祝UNIX"亿禧年" 图为当时所用的倒计时公告牌 无独有偶, 2012年7月13日也是一个黑色星期五, 而那天的UTC时间11时1分20秒对应着UNIX时间0x50000000(十六进制, 十进制值是1342177280). 不知到了那个时候, 会不会再次有人把它误解为又一次的UNIX时间错误？ - 未来, 2038年问题 - UTC时间2033年5月18日3时33分20秒, 是UNIX时间的第二个"亿禧年"(Billenniumm), 即2000000000. 然而, 第三个"亿禧年"(Billennium)则不会毫无障碍的来临, 在那之前, 人们先得解决正在变得著名的2038年问题. 和本世纪初的千年虫(Y2K Bug)问题类似, 2038年问题(Y2K38 BUG)更隐蔽, 而且更难解决. 我们知道计算机内部的一切都是二进制的, 也就是说1234567890在32位系统的内存里实际上是01001001 10010110 00000010 11010010. 这串32位二进制数中, 最高位被用来表示正负符号, 0代表整数, 1代表负数, 所以它能表示的最大数字就是01111111 11111111 11111111 11111111, 即214748367, 对应公历的UTC时间2038年1月19日3时14分7秒. 到这天的凌晨3时14分8秒, UNIX时间会溢出并变成10000000 00000000 00000000 00000000(十进制值-214748368), 也就是UTC时间1901年12月13日20时45分52秒, 引起和千年虫类似的混乱. 2038年问题的动画演示 - 救赎, 64位系统 - 2038年问题不仅比千年虫更隐蔽, 而且它的原因也更接近系统底层. 要解决这个问题, 最简单的方式是扩展UNIX时间的长度, 用64位数字来表示它. 64位二进制数的实际可用位数是63位, 最大表示到公历的UTC时间292277026596年12月4日. 如果那个时候人类文明还存在的话, 公元纪年很可能已经因为太难用而被抛弃了. 理想的情况是到2038年, 64位系统已经成为主流, 从而避免特意去修正这个问题所需要的大量开销. 否则, 人们就必须把新的64位时间拆分成两部分并分别保存在两个变量里, 这是一个麻烦而且效率低下的选择.
LinuxSpace 于 2009-05-24 20:56:11发表:
呵呵 未来的事情谁知道呢 我要是能未卜先知的话这个世界将会…………
haibian 于 2009-05-25 17:28:01发表:
纯属炒作
kpshare 于 2009-05-25 13:26:06发表:
好像不会。
紫色葡萄 于 2009-05-25 11:41:36发表:
干脆全世界约定，把2000年后归零，2001年就是01年，1999年就用上世纪99年来标识，这在计算机技术上肯定能实现，只是约定的问题。
jagub 于 2009-05-25 11:23:52发表:
好深奥的八卦新闻
me26659408 于 2009-05-25 07:55:10发表:
我现在都在用64位的了。。。
觉得非常好用。。。
f0rrest 于 2009-05-24 23:41:24发表:
2038年的时候，64位系统应该普及了。
yijunziran 于 2009-05-24 21:54:25发表:
随着社会的发展,这样的问题应该可以解决的吧
LinuxSpace 于 2009-05-24 21:36:03发表:
难道到时候就不能解决此问题了吗？？？
jyz19880823 于 2009-05-24 21:23:07发表:
<转来的>
1234567890是个节日, 一秒钟的节日. 它不是问题, 不是错误, 不是BUG. 我们人类使用的计时 系统是相当复杂的：秒是基本单位, 60秒为1分钟, 60分钟为1小时, 24小时是一天......如果计算机也使用相同的方式来计时, 那显然就要用多个变量来分别存放年月日时分秒, 不停的进行进位运算, 而且还要处理偶尔的闰年和闰秒以及协调不同的时区. 基于"追求简单"的设计理念, UNIX在内部采用了一种最简单的计时方式：
计算从 UNIX诞生[注释1]的UTC时间1970年 1月1日0时0分0秒起, 流逝的秒数. UTC时间1970年1月1日0时0分0秒就是UNIX时间0, UTC时间1970年1月2日0时0分0秒就是UNIX时间86400. 这个计时系统被所有的UNIX和UNIX-like系统继承了下来, 而且影响了许多非UNIX系统. POSIX标准推出后, 这个时间也被称为POSIX时间.
- 节日和庆祝 -
可能是因为人类是一种需要精神上的刺激的生物吧, 各种历法中都存在着各种拥有不同意义的节日. 其中, 很多节日仅仅由于日期的特殊性就被赋予了意义, 例如公历1月1日的新年, 11月11日的光棍节... 爱好节日的人们也没有放过UNIX时间. UTC时间2001年9月9日1时46分40秒, UNIX时间迎来了第一个"亿禧年"(Billennium)[注释2], 1000000000. UTC时间2005年3月18日1时58分31秒则是UNIX时间的光棍节, 1111111111. 刚刚过去的1234567890, 对应公历的UTC2009年2月13日23时31分30秒, 对东一区以东的时区来说是2月14日情人节, 以西的时区来说则刚好落在黑色星期五. 传统上认为黑色星五不吉利的西方媒体, 针对此事进行了玩笑性的报道, 结果被一些居住在其他时区的人们误读成了"UNIX时间错误".
丹麦哥本哈根的丹麦UNIX用户群组织庆祝UNIX"亿禧年" 图为当时所用的倒计时公告牌
无独有偶, 2012年7月13日也是一个黑色星期五, 而那天的UTC时间11时1分20秒对应着UNIX时间0x50000000(十六进制, 十进制值是1342177280). 不知到了那个时候, 会不会再次有人把它误解为又一次的UNIX时间错误？
- 未来, 2038年问题 -
UTC时间2033年5月18日3时33分20秒, 是UNIX时间的第二个"亿禧年"(Billenniumm), 即2000000000. 然而, 第三个"亿禧年"(Billennium)则不会毫无障碍的来临, 在那之前, 人们先得解决正在变得著名的2038年问题. 和本世纪初的千年虫(Y2K Bug)问题类似, 2038年问题(Y2K38 BUG)更隐蔽, 而且更难解决. 我们知道计算机内部的一切都是二进制的, 也就是说1234567890在32位系统的内存里实际上是01001001 10010110 00000010 11010010. 这串32位二进制数中, 最高位被用来表示正负符号, 0代表整数, 1代表负数, 所以它能表示的最大数字就是01111111 11111111 11111111 11111111, 即214748367, 对应公历的UTC时间2038年1月19日3时14分7秒. 到这天的凌晨3时14分8秒, UNIX时间会溢出并变成10000000 00000000 00000000 00000000(十进制值-214748368), 也就是UTC时间1901年12月13日20时45分52秒, 引起和千年虫类似的混乱.
2038年问题的动画演示
- 救赎, 64位系统 -
2038年问题不仅比千年虫更隐蔽, 而且它的原因也更接近系统底层. 要解决这个问题, 最简单的方式是扩展UNIX时间的长度, 用64位数字来表示它. 64位二进制数的实际可用位数是63位, 最大表示到公历的UTC时间292277026596年12月4日. 如果那个时候人类文明还存在的话, 公元纪年很可能已经因为太难用而被抛弃了. 理想的情况是到2038年, 64位系统已经成为主流, 从而避免特意去修正这个问题所需要的大量开销. 否则, 人们就必须把新的64位时间拆分成两部分并分别保存在两个变量里, 这是一个麻烦而且效率低下的选择.
LinuxSpace 于 2009-05-24 20:56:11发表:
呵呵 未来的事情谁知道呢 我要是能未卜先知的话这个世界将会…………