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
Nov 14 '05
248 10571
Thomas Matthews wrote: 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
[sarcasm on] I believe that we should all go out and hunt down these old Unix boxes and fix them. After all, this is way more important than getting Windows to stop that Blue Screen of Death during shutdown, holes in the security systems of servers and reduction of spam.
No, No, No. These old Unix boxes should be replaced with the latest,
state-of-the-art hardware.
In 2038 these boxes will be as slow as 4.77Mhz x86 processors
from 1980's. After all, there are at least 33 more years to develop a good panic. It will probably take that long to find these machines that are in charge of all the critical activities in the world. See, smart people don't use machines that say programs have executed illegal instructions (when it is the operating systems's fault).
Nope, stopping those Cell Phone spammers isn't as important because these cell phones are not controlling critical systems (and I know because I've either worked on them or seen them all).
So how will I panic, hmm, I don't know, but I've got a while to figure it out. I think I will use my computer that requires rebooting once a day, using appllications that can't communicate with the operating system, even though they are made by the same company. Yep, I search those web sites that will download spyware onto my machine so they can see how I am panicking.
Yep, I've just added another item to my worry list. Someday, I'll actually review it. :-)
[End of sarcasm]
It took ONE WEEK to verify that ALL systems were Y2K compliant.
No H1b visas were required!!!
T.M. Sommers wrote: Dan Pop wrote:
So, what's the next massive problem we have to worry about, now that we have just solved this one?
The Y10K problem, when all those 4-digit years everyone is so proud of become obsolete. If it took several years to fix just 40 years worth of software for the Y2K problem, just think how long it will take to fix 8000 years worth of software for the Y10K problem. We had better get started right away. There is no time to lose.
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c9******** **@sunnews.cern .ch... In <90************ *************@p osting.google.c om> us****@sta.sams ung.com
(Generic Usenet Account) writes:
Nope, this won't happen. By then, time_t will be a 64-bit type, as it already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
So, what's the next massive problem we have to worry about, now that we have just solved this one?
The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
current rate of 80 million/day, it will be completely gone within the lifespans
of some of the folks walking the earth today.
My solution is that I plan to be dead around 2040 or so.
<q@q.com> wrote in message news:40******** ******@q.com... No need to go into 'panic mode'. There is time to resolve this issue in a calm, cool and collected manner. Certainly 64 bit processors and/or long long data type will go a long way to resolving the issue. But there will NOT be any need to import thousands of H1b visas to fix this problem. Y2K was definitely blown way out of proportion! This was done by high priced consulting companies trying to justify their worth.
Yes, no need to panic. What we need here a small team of specialists, gathered
together in a committee. Over the course of their lives, with the benefit of
government funding, I'm sure this top-notch group of problem solvers will come
forth with a resolution to our problem.
Center of time is the United States Naval Observatory. http://tycho.usno.navy.mil/history.html http://tycho.usno.navy.mil/master.html http://tycho.usno.navy.mil/clocks.html
Jeff Schwab wrote: Mario Charest wrote:
My personal preference would be for a 256-bit number of picoseconds since the creation of the universe. It gives better precision than 1 second. It won't run out during the life of this universe. The only trouble is, we don't know accurately when that was. Wouldn't work, time isn't a constant. Doesn't show when your talking about seconds, but with picoseconds that will need to be taken into account. Number of picosecondes since creation of the universe isn't the same on top of mount Everest then at sea level. I wonder how NTP is going to deal with that LOL.
Gordon L. Burditt
I hereby nominate Bell Labs as the relative center of time, hence forth referred to as the Origin. The time at which any event occurs is not the local time, but the perceived time at the Origin "when" the event occurred, even if the event was not "then" directly observable from the Origin.
Gordon Burditt wrote: 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.
That depends on whether the system considers a time_t to be signed or unsigned. Some UNIX systems consider the time range of a traditional 32-bit time_t to be 1970 thru something like 2106, not 1901 thru 2038.
The obvious cure is to switch to the CP/M standard date format,
which is a 16 bit unsigned value expressing the count of days
since 1977-12-31. 0 is 'unknown'. This postpones the problem
until about 2157 or so.
Quite a good troll, he didn't need to prod it further.
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
Joona I Palaste <pa*****@cc.hel sinki.fi> scribbled the following: Alan Balmer <al******@att.n et> scribbled the following: On Thu, 27 May 2004 14:42:45 -0700, Tobin Fricke <fr****@ocf.ber keley.edu> wrote:On Thu, 27 May 2004, Alan Balmer wrote:
I wrote:> 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?
The only reason it didn't happen was because we fixed it.
I don't recall you getting anywhere near my coffee machine or volkswagen.
Vastly overblown it was.
What was overblown was Joona's rhetoric, which was why I ignored it. I presume you didn't see any dogs turning into cats, either.
There were real problems. Most of them were fixed in time to ensure your comfort.
I am quite sure I've heard stories about everything having an electronic timer stopping working in 2000. http://www.rinkworks.com/stupid/cs_y2k.shtml
--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Holy Banana of this, Sacred Coconut of that, Magic Axolotl of the other."
- Guardian in "Jinxter"
"Gordon Burditt" <go***********@ burditt.org> wrote in message
news:c9******** @library2.airne ws.net... My personal preference would be for a 256-bit number of picoseconds since the creation of the universe. It gives better precision than 1 second. It won't run out during the life of this universe. The only trouble is, we don't know accurately when that was.
Sez right in the Old Testament:
"In the beginning".
-Mike q@q.com <q@q.com> scribbled the following
on comp.lang.c: No need to go into 'panic mode'. There is time to resolve this issue in a calm, cool and collected manner. Certainly 64 bit processors and/or long long data type will go a long way to resolving the issue. But there will NOT be any need to import thousands of H1b visas to fix this problem. Y2K was definitely blown way out of proportion! This was done by high priced consulting companies trying to justify their worth.
What's with the obsession about H1b visas then, eh?
--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/ Jeff Schwab wrote:
Mario Charest wrote:
My personal preference would be for a 256-bit number of picoseconds since the creation of the universe. It gives better precision than 1 second. It won't run out during the life of this universe. The only trouble is, we don't know accurately when that was.
Wouldn't work, time isn't a constant. Doesn't show when your talking about seconds, but with picoseconds that will need to be taken into account. Number of picosecondes since creation of the universe isn't the same on top of mount Everest then at sea level. I wonder how NTP is going to deal with that LOL. Gordon L. Burditt
I hereby nominate Bell Labs as the relative center of time, hence forth referred to as the Origin. The time at which any event occurs is not the local time, but the perceived time at the Origin "when" the event occurred, even if the event was not "then" directly observable from the Origin.
q@q.com top-posted: Center of time is the United States Naval Observatory. http://tycho.usno.navy.mil/history.html http://tycho.usno.navy.mil/master.html http://tycho.usno.navy.mil/clocks.html
There are plenty of existing "centers of time," and I might also mention
Greenwich. I'm suggesting a center not to be used as an actual point of
physical measurement, but as a conceptual reference point for use in
software. This thread has been closed and replies have been disabled. Please start a new discussion. |