Myself

A Thousand Marbles

1000 marbles
The older I get, the more I enjoy Saturday mornings. Perhaps it's the quiet solitude that comes with being the first to rise, or maybe it's the unbounded joy of not having to be at work. Either way, the first few hours of a Saturday morning are most enjoyable.
A few weeks ago, I was shuffling toward the basement ham-shack with a steaming cup of coffee in one hand and the morning paper in the other.
What began as a typical Saturday morning turned into one of those lessons that life seems to hand you from time to time. Let me tell you about it.
I turned the dial up into the phone portion of the band on my ham radio in order to listen to a Saturday morning swap net. Along the way, I came across an older sounding chap, with a tremendous signal and a golden voice.
You know the kind; he sounded like he should be in the broadcasting business.
He was telling whomever he was talking with something about "a thousand marbles." I was intrigued and stopped to listen to what he had to say.
"Well, Tom, it sure sounds like you're busy with your job. I'm sure they pay you well but it's a shame you have to be away from home and your family so much. Hard to believe a young fellow should have to work sixty or seventy hours a week to make ends meet. Too bad you missed your daughter's dance recital he continued, "Let me tell you something Tom, something that has helped me keep a good perspective on my own priorities."
And that's when he began to explain his theory of a "thousand marbles."
"You see, I sat down one day and did a little arithmetic. The average person lives about seventy-five years. I know, some live more and some live less, but on average, folks live about seventy-five years. Now then, I multiplied 75 times 52 and I came up with 3900, which is the number of Saturdays that the average person has in their entire lifetime."
"Now, stick with me, Tom, I'm getting to the important part. It took me until I was fifty-five years old to think about all this in any detail" he went on, "and by that time I had lived through over twenty-eight hundred Saturdays. I got to thinking that if I lived to be seventy-five, I only had about a thousand of them left to enjoy. So I went to a toy store and bought every single marble they had. I ended up having to visit three toy stores to round up 1000 marbles. I took them home and put them inside a large, clear plastic container right here in the sack next to my gear."
"Every Saturday since then, I have taken one marble out and thrown it away. I found that by watching the marbles diminish, I focus more on the really important things in life. There is nothing like watching your time here on this earth run out to help get your priorities straight."
"Now let me tell you one last thing before I sign-off with you and take my lovely wife out for breakfast. This morning, I took the very last marble out of the container. I figure that if I make it until next Saturday then I have been given a little extra time. And the one thing we can all use is a little more time."
"It was nice to meet you Tom, I hope you spend more time with your family, and I hope to meet you again here on the band. This is 75 Year Old Man, K9NZQ, clear and going QRT, good morning!"
You could have heard a pin drop on the band when this fellow signed off. I guess he gave us all a lot to think about. I had planned to work on the antenna that morning, and then I was going to meet up with a few hams to work on the next club newsletter. Instead, I went upstairs and woke my wife up with a kiss. "C'mon honey, I'm taking you and the kids to breakfast." "What brought this on?" she asked with a smile. "Oh, nothing special, it's just been a long time since we spent a Saturday together with the kids. And hey, can we stop at a toy store while we're out? I need to buy some marbles....

The Year 2038.....

The Year 2038 Problem


Test it now...

steps...

1. login to yahoo messenger

2. send instant message to anyone - fine its working...

3. now, change ur system date to 19-Jan-2038, 03:14:07 AM or above

(as mentioned in mail)

4. Confirm weather ur date is changed

5. again send instant message to anyone...

Your YM crahes....

* * * 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 blackout), 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 midnight) 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 January 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.

A quick check with the following Perl script may help determine if your
computers will have problems (this requires Perl to be installed on your
system, of course):

#!/usr/bin/perl

# Use POSIX (Portable Operating System Interface) use POSIX;

# Set the Time Zone to GMT (Greenwich Mean Time) for

date calculations.

$ENV{'TZ'} = "GMT";

# Count up in seconds of Epoch time just before and

after the critical event.

for ($clock = 2147483641; $clock < 2147483651;

$clock++)

{

print ctime($clock);

}

For example, the output of this script on Debian GNU/Linux (kernel 2.4.22)
(An affected system) will be

# ./2038.pl

Tue Jan 19 03:14:01 2038

Tue Jan 19 03:14:02 2038

Tue Jan 19 03:14:03 2038

Tue Jan 19 03:14:04 2038

Tue Jan 19 03:14:05 2038

Tue Jan 19 03:14:06 2038

Tue Jan 19 03:14:07 2038

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Solution

"The best way to predict the future is to engineer it." Consider
testing your mission-critical code well ahead of time on a
non-production test platform set just before the critical date. For more
general applications, just using large types for storing dates will do the
trick in most cases. For example, in GNU C, 64-bits (a "long " type) is
sufficient to keep the

time from rolling over for literally geological eons This just means any
executables the operating systems runs will always get the correct time
reported to them when queried in the correct manner. It doesn't stop the
executables you may still want to be worried about
Well-written programs can simply be recompiled with a new version of the
library that uses, for example, 8-byte values for the storage
format. This is possible because the library encapsulates the whole time
activity with its own time types and functions (unlike most
mainframe programs, which did not standardize their date formats or
calculations). So the Year 2038 problem should not be nearly as hard to
fix as the Y2K problem was.

Admittedly, some don't feel that this impending disaster will strike too
many people. They reason that, by the time 2038 rolls around, most
programs will be running on 64-bit or even 128-bit computers. In a 64-bit
program, a time_t could represent any date and time in the
future out to 292 000 000 000 A.D., which is about 20 times the
currently estimated age of the universe. The problem with this kind of
optimism is the same root problem behind most of the Year 2000

concerns that plagued the software industry in previous years: Legacy
Code. Even if every PC in the year 2038 has a 64-bit CPU, there will be a
lot of older 32-bit programs running on them.

The greatest danger with the Year 2038 Problem is its invisibility. The
more-famous Year 2000 is a big, round number; it only takes a few seconds
of thought, even for a computer-illiterate person, to imagine what might
happen when 1999 turns into 2000. But January 19, 2038 is not nearly as
obvious. Software companies will probably not think of trying out a Year
2038 scenario before doomsday strikes. Of course, there will be some
warning ahead of time. Scheduling software, billing programs, personal
reminder calendars, and other such pieces of code that set dates in the
near future will fail as soon as one of their target dates exceeds
19-Jan-2038, assuming a time_t is used to store them.

Good luck, and hope no ones flying car breaks down in 2038