2038年的问题 [英] The Year 2038 Problem
问题描述
根据Google的Usenet档案
[ http://groups.google.com/googlegroup...ounce_20.html] ，
首次讨论Usenet上的Y2K问题是在1月18日/>
1985 [ http：// groups .google.com /组？THRE ... 0％40reed.UUCP] 。
是在问题出现之前的15年。即便如此，它还是b $ b，当D-day接近
时，我们争先恐后地争抢。
虽然Y2K恐慌被夸大了，我们面前有一个很大的问题 - 2038年的问题。在1月1日星期一
18 21:14:07 2038，Unix秒 - 自 - 纪元计数将翻转。
之后，时间在Unix系统将读作12月13日星期五
14:45:52 1901.
恕我直言，如果我们想避免我们目睹的最后一分钟恐慌<在上一个千年结束时（同时追求Y2K
问题），我们应该开始讨论可行的解决方案
到这个问题现在。建立共识需要很长时间才能达成共识，并提出一个解决方案，大多数（如果不是全部）人都可以接受。我们还需要相当长的时间来测试现实世界中所有可能的解决方案，以确定解决方案
是否真的按预期工作。我们可能还需要制定一套
恢复策略，如果问题在星期一早上的某个系统中显现出来的话。这一切都需要时间。所以，正如已故的Todd
Beamer会说：让我们滚动。
Bhat
" Generic Usenet Account" <我们**** @ sta.samsung.com>在消息中写道
新闻：90 ************************* @ posting.google.co m ...
< snip>虽然Y2K恐慌被夸大了，但
< snip>
白痴!!它并没有夸大其词。一点都不事实是，
我们做了很好的工作。
- Bob Day
< blockquote> Bob Day< xx ***** @ yyyyyyy.com>在comp.lang.c上潦草地写下以下
：
" Generic Usenet Account" <我们**** @ sta.samsung.com>在消息中写道
新闻：90 ************************* @ posting.google.co m ...
< ; snip>虽然Y2K恐慌被证明是夸大其词，但< snip>
白痴!!它并没有夸大其词。一点都不事实是，
我们做了很好的工作。
哦，是吗？从你的咖啡制造商到你的汽车发动机的火花塞一直停止工作的所有这些故事怎么样呢？1999年的第二次改变到2000年的确切时间？如果那'不是'夸大其词'b $ b夸大其词'，那是什么？狗变成猫，反之亦然？
-
/ - Joona Palaste（pa*****@cc.helsinki.fi） - ------------芬兰-------- \
\-- http://www.helsinki.fi/~palaste -------------------- - 规则！ -------- /
C ++看起来像线路噪音。
- Fred L. Baube III
Generic Usenet Account写道：
根据谷歌的Usenet档案
[ http://groups.google.com/googlegroup...ounce_20.html] ，
首次讨论Usenet上的Y2K问题发生在1月18日
1985 [ http://groups.google.com/groups?thre...0%40reed.UUCP] 。在问题出现之前15年是好的。即便如此，事实证明，当D日即将来临时，我们还在争抢掩护。
虽然Y2K恐慌被证明是夸大其词，但我们确实有我们面前的一个大问题------ 2038年的问题。在20月31日星期一
18 21:14:07，Unix秒 - 自 - 纪元计数将翻转。
之后，Unix系统上的时间将读作12月13日星期五
1901年14:45:52。
恕我直言，如果我们想避免在上一个千年结束时我们目睹的最后一分钟恐慌（同时追求Y2K <问题），我们现在应该开始讨论这个问题的可行解决方案。建立共识需要很长时间，并提出一个大多数（如果不是全部）人都能接受的解决方案。我们还需要相当长的时间来测试现实世界中所有可能的解决方案，以确定解决方案是否真的按预期工作。我们可能还需要开发一套恢复策略，如果问题在星期一早上的某个系统中显现出来。这一切都需要时间。所以，正如已故的Todd
Beamer所说的那样：让我们滚动吧。
Bhat
2038年所有操作系统（包括Unix）将有64位
来保存日期值，64位翻转
将在1970年1月1日之后的2920亿年发生。
- Dario
As per Google''s Usenet archives
[http://groups.google.com/googlegroup...ounce_20.html], the
first discussion of the Y2K problem on the Usenet was on January 18
1985 [http://groups.google.com/groups?thre...0%40reed.UUCP]. That
is a good 15 years before the problem manifested. Even then, it
turned out, we were scrambling for cover when the D-day was
approaching.
Although the Y2K scare turned out to be vastly overblown, we do have a
massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
After that, the time on the Unix systems will read as Fri Dec 13
14:45:52 1901.
IMHO, if we want to avoid the last minute panic that we witnessed
towards the end of the last millennium (while pursuing the Y2K
problem), we should begin the process of debating the viable solutions
to this problem NOW. It will take a long time for the consensus to be
built, and to come up with a solution that most (if not all) people
find acceptable. We also need considerable time to test out all
possible solutions in the real world, to decide if the solutions
really work as expected. We may also need to develop a suite of
recovery strategies should the problem manifest in some system on that
fateful Monday morning. All this takes time. So, as the late Todd
Beamer would have said: Let''s roll.
Bhat
"Generic Usenet Account" <us****@sta.samsung.com> wrote in message
news:90*************************@posting.google.co m...
< snip >Although the Y2K scare turned out to be vastly overblown,
< snip >
Idiot!! It wasn''t "vastly overblown" at all. The fact is,
we did a damn good job fixing it.
-- Bob Day
Bob Day <xx*****@yyyyyyy.com> scribbled the following
on comp.lang.c:"Generic Usenet Account" <us****@sta.samsung.com> wrote in message
news:90*************************@posting.google.co m...
< snip >Although the Y2K scare turned out to be vastly overblown, < snip >
Idiot!! It wasn''t "vastly overblown" at all. The fact is,
we did a damn good job fixing it.
Oh yeah? How about all those stories about everything from your coffee
maker to your car engine''s sparkplugs stopping working on the exact
second the year 1999 changes into the year 2000? If that''s not "vastly
overblown", what is? Dogs turning into cats and vice versa?
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"C++ looks like line noise."
- Fred L. Baube III
Generic Usenet Account wrote:
As per Google''s Usenet archives
[http://groups.google.com/googlegroup...ounce_20.html], the
first discussion of the Y2K problem on the Usenet was on January 18
1985 [http://groups.google.com/groups?thre...0%40reed.UUCP]. That
is a good 15 years before the problem manifested. Even then, it
turned out, we were scrambling for cover when the D-day was
approaching.
Although the Y2K scare turned out to be vastly overblown, we do have a
massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
After that, the time on the Unix systems will read as Fri Dec 13
14:45:52 1901.
IMHO, if we want to avoid the last minute panic that we witnessed
towards the end of the last millennium (while pursuing the Y2K
problem), we should begin the process of debating the viable solutions
to this problem NOW. It will take a long time for the consensus to be
built, and to come up with a solution that most (if not all) people
find acceptable. We also need considerable time to test out all
possible solutions in the real world, to decide if the solutions
really work as expected. We may also need to develop a suite of
recovery strategies should the problem manifest in some system on that
fateful Monday morning. All this takes time. So, as the late Todd
Beamer would have said: Let''s roll.
Bhat
In 2038 all OS (Unix included) will have 64 bits
to hold a Date value and with 64 bits the rollover
will happen 292 billion years after 1/1/1970.
- Dario
这篇关于2038年的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
