您知道格林威治時間2038年1月19日3時14分08秒會發生什麼事嗎?
時間 , 2038 年 1 月 19 日 3 時 14 分 08 秒.
33 年後的一個看似平凡的日子, 但對於很多大機構的 IT 人員來說, 那天可能比 2000 年 1 月 1 日 0 時 0 分 01 秒的千年蟲危機更危險, 因為好多人都不知道他們使用的操作系統或日常使用的軟件內的時間系統, 可能有 year 2038 bug...
year 2038 bug 到底是什麼呢?
好多作業系統, 列如 UNIX 及 LINUX 的時間系統是由「新紀元時間」Epoch 開始計算起, 單位為秒, Epoch 則是指定為格林威治時間 1970 年 1 月 1 日 0 時 0 分 0 秒,
目前大部份的 UNIX 系統都是用 32 位元來記錄時間, 正數表示為 1970 以後, 負數則表示 1970 年以前.
2^31/86400(s) = 24855.13481(天) ~ 68.0958(年)
1970+68.0958 = 2038.0958
1970-68.0958 = 1901.9042
準確的時間為 2038 年 1 月 19 日 3 時 14 分 08 秒, 那一刻時間將會轉為負數, 變成 1901 年 12 月 13 日 黑色星期五 20 時 45 分 52 秒，然後您在使用的的電腦系統可能就會罷工了, 這就是所謂的 year 2038 bug, 在大部份的 UNIX 上, 並沒有所謂 Y2K 問題, 不過都有 2038 年問題.
在一些 64 位元的平薹上, 例如 Digital Alpha、SGI、Sparc 等等, 則用 64 位元來表示時間.
2^63/86400 ~ 1E14(天) ~ 2.92E11(年)
大約是 292 億年, 因此使用 64 位元的電腦大多可以順利過度.
雖然許多人認為 UNIX 的 2038 年問題會隨著科技的進步, 而將電腦逐步汰換成 64 位元電腦因此無須擔心, 但我個人相信, 在 2038 年依然會有許多狀況出現, 因為就事實而言, 目前許多 UNIX 系統都有足夠的能力服役到 2038 年而毫無問題, 因此如果有意添購電腦, 最好是選購 64 位元電腦.
講了那麼多, 可能您會說都唔關我事, 我都不用 UNIX 或 LINUX 的, 對, 大多數人已在用 windows 2000 or xp, 但您在用的會計系統或一些對時間很敏感的軟件, 而設計它們的 programmer 使用了一些有 year 2038 bug 的程式庫時一樣會出事, 就如以下一段 Perl script 我在 windows xp sp1 下用 ActivePerl-5.8.6.811 來 run 它, 都出現問題, 它停了在 Mon Jan 18 22:14:07 2038 如沒有問題程式會顯示 Mon Jan 18 22:14:08 2038 及其後的日子.
#!/usr/bin/perl
#
# I've seen a few versions of this algorithm
# online, I don't know who to credit. I assume
# this code to by GPL unless proven otherwise.
# Comments provided by William Porquet, February 2004.
# You may need to change the line above to
# reflect the location of your Perl binary
# (e.g. "#!/usr/local/bin/perl").
# Also change this file's name to '2038.pl'.
# Don't forget to make this file +x with "chmod".
# On Linux, you can run this from a command line like this:
# ./2038.pl
use POSIX;
# Use POSIX (Portable Operating System Interface),
# a set of standard operating system interfaces.
$ENV{'TZ'} = "GMT";
# Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
for ($clock = 2147483641; $clock < 2147483651; $clock++)
{
print ctime($clock);
}
# Count up in seconds of Epoch time just before and after the critical event.
# Print out the corresponding date in Gregorian calendar for each result.
# Are the date and time outputs correct after the critical event second?
參考網址:
http://www.deepsky.com/~merovech/2038.html
http://computer.howstuffworks.com/question75.htm
http://www.2038bug.com/index.html
