| Y2k of 2038 [message #196459] |
Sat, 15 April 2006 19:07  |
 |
Jaspah
Messages: 1478
Registered: July 2003
Location: Syracuse, New York
Karma: 0
|
General (1 Star) |
|
|
It's an interesting read. Someone with Yahoo Messenger should try this. 
| The bowls of ze Intarweb |
This news has been published in one of the daily news paper...read on
*Year 2038..Again the replica of Y2K*
Note: This is just for FYI only, Please Don't try
this. This is true and if you do this then your
network based applications will not work.
The Year 2038 Problem
Triaging steps...
1. login to yahoo messenger
2. send instant message to anyone - fine its
working...
3. now, change your system date to 19-Jan-2038,
03:14:07 AM or above
4. Confirm weather your date is changed
5. again send instant message to anyone...
Your YM crashes...
* * * YES ALL NETWORK BASED APPLICATION WILL NOT WORK
NOW * * *
*Why...
What is it?*
Starting at GMT 03:14:07, Tuesday, January 19, 2038,
It is expected to see lots of systems around the world
breaking magnificently: satellites falling out of
orbit, massive power outages (like the 2003 North
American black out), hospital life support system
failures, phone system interruptions, banking errors,
etc. One second after this critical second, many of
these systems will have wildly inaccurate date
settings, producing all kinds of unpredictable
consequences. In short, many of the dire predictions
for the year 2000 are much more likely to actually
occur in the year 2038! Consider the year 2000 just a
dry run. In case you think we can sit on this issue
for another 30 years before addressing it, consider
that reports of temporal echoes of the 2038 problem
are already starting to appear in future date
calculations for mortgages and vital statistics!
In the first month of the year 2038 C.E. many
computers will encounter a date-related bug in their
operating systems and/or in the applications they run.
This can result in incorrect and wildly inaccurate
dates being reported by the operating system and/or
applications. The effect of this bug is hard to
predict, because many applications are not prepared
for the resulting "skip" in reported time anywhere
from 1901 to a "broken record" repeat of the reported
time at the second the bug occurs. Also, may make
some small adjustment to the actual time the bug
expresses itself. This bug to cause serious problems
on many platforms, especially Unix and Unix-like
platforms, because these systems will "run out of
time".
What causes it?
Time_t is a data type used by C and C++ programs to
represent dates and times internally. (Windows
programmers out there might also recognize it as the
basis for the CTime and CTimeSpan classes in MFC.)
time_t is actually just an integer, a whole number,
that counts the number of seconds since January 1,
1970 at 12:00 AM Greenwich Mean Time. A time_t value
of 0 would be 12:00:00 AM (exactly midnight)
1-Jan-1970, a time_t value of 1 would be 12:00:01 AM
(one second after midnig ht) 1-Jan-1970, etc..
some example times and their exact time_t
representations:
Date & time time_t representation
1-Jan-1970, 12:00:00 AM GMT 0
1-Jan-1970, 12:01:00 AM GMT 60
1-Jan-1970, 01:00:00 AM GMT 3 600
2-Jan-1970, 12:00:00 AM GMT 86 400
1-Jan-1971, 12:00:00 AM GMT 31 536 000
1-Jan-1972, 12:00:00 AM GMT 63 072 000
1-Jan-2038, 12:00:00 AM GMT 2 145 916 800
19-Jan-2038, 03:14:07 AM GMT 2 147 483 647
By the year 2038, the time_t representation for the
current time will be over 2 140 000 000. And that's
the problem. A modern 32-bit computer stores a "signed
integer" data type, such as time_t, in 32 bits. The
first of these bits is used for the positive/negative
sign of the integer, while the remaining 31 bits are
used to store the number itself.
The highest number these 31 data bits can store works
out to exactly 2 147 483 647. A time_t value of this
exact number, 2 147 483 647, represents Janu ary 19,
2038, at 7 seconds past 3:14 AM Greenwich Mean Time.
So, at 3:14:07 AM GMT on that fateful day, every
time_t used in a 32-bit C or C++ program will reach
its upper limit.
One second later, on 19-January-2038 at 3:14:08 AM
GMT, disaster strikes. When a signed integer reaches
its maximum value and then gets incremented, it wraps
around to its lowest possible negative value. This
means a 32-bit signed integer, such as a time_t, set
to its maximum value of 2 147 483 647 and then
incremented by 1, will become -2 147 483 648. Note
that "-" sign at the beginning of this large number. A
time_t value of -2 147 483 648 would represent
December 13, 1901 at 8:45:52 PM GMT.
So, if all goes normally, 19-January-2038 will
suddenly become 13-December-1901 in every time_t
across the globe, and every date calculation based on
this figure will go haywire. And it gets worse. Most
of the support functions that use the time_t data type
cannot handle negative time_t values at all. They
simply fail and return an error code.
|
I love all these OMGWTF ARMAGEDDON!?! theories people come up with.
|
|
|
|
| Re: Y2k of 2038 [message #196466 is a reply to message #196459] |
Sat, 15 April 2006 19:30  |
 |
Renx
Messages: 2321
Registered: April 2003
Location: Canada
Karma: 0
|
General (2 Stars)
Category Moderator |
|
|
"massive power outages (like the 2003 NorthAmerican black out)"
That was due to a heatwave that caused record demand for power. The power grid is old and needs to be updated. Things like that have absolutely nothing to do with the date at all..
~Canucck
[Updated on: Sat, 15 April 2006 19:31] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Y2k of 2038 [message #196500 is a reply to message #196459] |
Sat, 15 April 2006 23:05 |
 |
Oblivion165
Messages: 3468
Registered: June 2003
Location: Hendersonville, North Car...
Karma: 0
|
General (3 Stars) |
|
|
I set mine to 2040 and sure enough YIM MSN ICQ all crashed when i tried to send a message.
But come on, this will be resolved LONG before its a problem.
WOL: Ob165ion Skype: Oblivion165 Yahoo Instant Messenger: CaptainJohn165
|
|
|
|
| Re: Y2k of 2038 [message #196501 is a reply to message #196500] |
Sat, 15 April 2006 23:12 |
Homey
Messages: 1084
Registered: February 2003
Location: Canada
Karma: 0
|
General (1 Star) |
|
|
| Oblivion165 wrote on Sun, 16 April 2006 02:05 |
I set mine to 2040 and sure enough YIM MSN ICQ all crashed when i tried to send a message.
But come on, this will be resolved LONG before its a problem.
|
Exactly, just like how the y2k bug was fixed in advance, except this time i'm sure it will be much more in advance.
Homey
|
|
|
|
| Re: Y2k of 2038 [message #196515 is a reply to message #196459] |
Sun, 16 April 2006 00:32 |
 |
Crimson
Messages: 7431
Registered: February 2003
Location: Phoenix, AZ
Karma: 0
|
General (5 Stars)
ADMINISTRATOR |
|
|
This is actually true, but I'm sure by even 5-10 years from now we'll be past 32 bits.
I'm the bawss.
|
|
|
|
|
|
|
|
| Re: Y2k of 2038 [message #196635 is a reply to message #196459] |
Sun, 16 April 2006 16:28 |
=HT=T-Bird
Messages: 712
Registered: June 2005
Karma: 0
|
Colonel |
|
|
Most OS'es have already switched over to 64-bit time_t's already...
HTT-Bird (IRC)
HTTBird (WOL)
Proud HazTeam Lieutenant.
BlackIntel Coder & Moderator.
If you have trouble running BIATCH on your FDS, have some questions about a BIATCH message or log entry, or think that BIATCH spit out a false positive, PLEASE contact the BlackIntel coding team and avoid wasting the time of others.
|
|
|
|
|
|
|
|
| Re: Y2k of 2038 [message #196716 is a reply to message #196459] |
Mon, 17 April 2006 02:58 |
 |
light
Messages: 988
Registered: January 2005
Karma: 0
|
Colonel |
|
|
It seems the math is right. However, it's not going to be an issue if people can see it coming 30 years down the track.
I bet that some old 32 bit systems will go down, but anything important will either be patched or 64bit.
|
|
|
|
Search
Help
Members
Register
Login
Home
