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 248  10158 
"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
In <90*************************@posting.google.com> us****@sta.samsung.com (Generic Usenet Account) writes: 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.
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):
lx64:~/tmp 13> cat test.c
#include <time.h>
#include <stdio.h>
#include <limits.h>
int main()
{
printf("%d\n", (int)sizeof(time_t) * CHAR_BIT);
return 0;
}
lx64:~/tmp 14> gcc test.c
lx64:~/tmp 15> ./a.out
64
So, what's the next massive problem we have to worry about, now that we
have just solved this one?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
> 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.
Which is why we probably won't ever need any more than
64 bits to hold dates.
Our galaxy will probably have collapsed by then, and
maybe along with the whole universe.
On 27 May 2004 17:03:29 GMT, Joona I Palaste <pa*****@cc.helsinki.fi>
wrote: 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?
The only reason it didn't happen was because we fixed it.
I suppose the world would have appreciated it more if we'd let
everything go to hell and then became heroes by fixing it afterward.
--
Al Balmer
Balmer Consulting re************************@att.net
"Guillaume" <gr*******@NO-SPAMmail.com> wrote in message
news:40*********************@news.club-internet.fr... 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.
Which is why we probably won't ever need any more than
64 bits to hold dates.
Our galaxy will probably have collapsed by then, and
maybe along with the whole universe.
Hoping we haven't contacted any kind of higher intelligence Humans from
other planet and they want us to modify our date to theirs.
Dan Pop <Da*****@cern.ch> wrote: 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):
The time_t might have 64-bit but are you sure that every occurence where
the time is copied or used is as well?
O. Wyss
--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c9**********@sunnews.cern.ch... In <90*************************@posting.google.com> us****@sta.samsung.com
(Generic > So, what's the next massive problem we have to worry about, now that we
have just solved this one?
Creating sufficient storage for archival of moronic Usenet posts. :-)
-Mike
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.
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
Otto Wyss wrote: Dan Pop <Da*****@cern.ch> wrote:
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):
The time_t might have 64-bit but are you sure that every occurence where
the time is copied or used is as well?
O. Wyss
34 years ago was 1970; how many programs from that era are running on
modern hardware without having been recompiled?
"Generic Usenet Account" <us****@sta.samsung.com> wrote in message
news:90*************************@posting.google.co m... 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.
You mean systems which use a signed 32-bit int for time_t. Modern systems
use a 64-bit int for time_t, so the problem is moot (unless you're running
code in 2038 that hasn't been recompiled since the early 1990s).
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.
There already is a solution, consensus for it, and implementations of it.
The sky is NOT falling.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
"Otto Wyss" <ot*******@orpatec.ch> wrote in message
news:1gegpbt.ot7t0q1p5gqogN%ot*******@orpatec.ch.. . Dan Pop <Da*****@cern.ch> wrote:
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):
The time_t might have 64-bit but are you sure that every occurence where
the time is copied or used is as well?
If someone copies a time_t into a variable of any other type, they may be
invoking undefined behavior, which means it's not the Standard's problem,
it's the coder's.
time_t exists for a reason, just like size_t. Use them.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
In 'comp.lang.c', Alan Balmer <al******@att.net> 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 suppose the world would have appreciated it more if we'd let
everything go to hell and then became heroes by fixing it afterward.
I believe you. I don't understand why people are so 'hot' about this topic.
Maybe, I just can make the difference between what the TV says and the real
world...
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
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.
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]
--
Thomas Matthews
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq: http://www.raos.demon.uk/acllc-c++/faq.html
Other sites: http://www.josuttis.com -- C++ STL Library book
>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.
There is also no prohibition of using a larger integer for a time_t.
This isn't an ANSI C problem. It may be a POSIX problem, although
I'm not sure whether POSIX says anything about time_t's having to
have exactly 32 bits. (Some systems already use 64 bits, I believe,
and those processors will become more popular as it gets closer to
2038, if they're not obsoleted by the 4096-bit processors.)
Now, this creates problems if you're storing time_t's on disk as, for
example, file timestamps, but it doesn't rule out converting the filesystem
including 0-extending or sign-extending the time_t to more bits.
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.
Gordon L. Burditt
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.
On Thu, 27 May 2004, Alan Balmer 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.
--tobin
> Hoping we haven't contacted any kind of higher intelligence Humans from other planet and they want us to modify our date to theirs.
Hehe, that might happen indeed.
Who knows, maybe they'll want to store dates with a femtosecond
resolution. We wouldn't get very far with 64 bits, then...
On Thu, 27 May 2004 14:42:45 -0700, Tobin Fricke
<fr****@ocf.berkeley.edu> wrote: On Thu, 27 May 2004, Alan Balmer 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.
--
Al Balmer
Balmer Consulting re************************@att.net
On 27 May 2004 21:27:14 GMT, go***********@burditt.org (Gordon
Burditt) wrote: [snip]
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.
Gordon L. Burditt
< mode = nitpick >
Not quite accurate. We know precisely when the universe started; at
time = 0. The problem is that we don't know what the time is now.
< mode = whatever_passes_for_normal >
rossum
--
The Ultimate Truth is that there is no Ultimate Truth
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:c9********@library2.airnews.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.
Given we want to represent times in the past as well as the future, it would
be reasonable to fix 'now' (give or take) as midpoint in the range, so why
not arbitrarily pick
00:00:00.000 on the morning of January First 0001 as
1-followed-by-255-zeroes (256-bit unsigned value).
--
Roger
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:c9********@library2.airnews.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.
You assume a "when" exists; relativity says that's impossible.
Relativity aside, there's nothing preventing time_t from being a
floating-point number whose zero is at a particular epoch. Epsilon of the
chosen type determines the precision of your clock.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
# 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.
By 2000, OSes could afford four digit years. The problem wasn't new
software that included enough space. The problem was old files, old
databases, and old software (some without source code). If you can
guarentee that changing time_t to 64 bits will automatically convert
32 bit values in existing files, databases, and object code, then
you're right, no problem.
If the conversion is not automatic, then it's Y2K all over again.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
What kind of convenience store do you run here?
Otto Wyss wrote: Dan Pop <Da*****@cern.ch> wrote: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):
The time_t might have 64-bit but are you sure that every occurence where
the time is copied or used is as well?
By 2038 opensourced software will be abundant and everyone will laugh at
those still using proprietry software ;->
--
Ben M.
"Guillaume" <gr*******@NO-SPAMmail.com> wrote in message
news:40*********************@news.club-internet.fr... Hoping we haven't contacted any kind of higher intelligence Humans from
other planet and they want us to modify our date to theirs.
Hehe, that might happen indeed.
Who knows, maybe they'll want to store dates with a femtosecond
resolution. We wouldn't get very far with 64 bits, then...
LOL ... And then if we ever colonized the moon and mars and then we have
real-time databases with planet earth , what's time and date is at the
moon/mars compared to the earth :-) ..... I'll be dust by that time
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
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.
Alan Balmer <al******@att.net> scribbled the following: On Thu, 27 May 2004 14:42:45 -0700, Tobin Fricke
<fr****@ocf.berkeley.edu> wrote:On Thu, 27 May 2004, Alan Balmer 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.
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The truth is out there, man! Way out there!"
- Professor Ashfield
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.ch> wrote in message
news:c9**********@sunnews.cern.ch... In <90*************************@posting.google.com> us****@sta.samsung.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.helsinki.fi> scribbled the following: Alan Balmer <al******@att.net> scribbled the following: On Thu, 27 May 2004 14:42:45 -0700, Tobin Fricke
<fr****@ocf.berkeley.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.helsinki.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.airnews.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.helsinki.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.
AngleWyrm wrote:
<snip> 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.
Last time I heard a prediction on that (which wasn't all that recent,
admittedly), trend analysis on usage vs known (or suspected) supplies
put the run-out point around 2025.
So yeah, I think a /lot/ of folks here will see the end.
My solution is that I plan to be dead around 2040 or so.
15 years after the oil runs out and we're all paying US$20/gallon for
vehicle grade alcohol :>
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
Guillaume wrote: 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.
Which is why we probably won't ever need any more than
64 bits to hold dates.
Our galaxy will probably have collapsed by then, and
maybe along with the whole universe.
God forbid I'm not running at least 256 bits by then. ;)
Myren
"Stephen Sprunk" <st*****@sprunk.org> writes: "Gordon Burditt" <go***********@burditt.org> wrote in message
news:c9********@library2.airnews.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.
You assume a "when" exists; relativity says that's impossible.
Relativity aside, there's nothing preventing time_t from being a
floating-point number whose zero is at a particular epoch. Epsilon of the
chosen type determines the precision of your clock.
With a floating-point type, the precision of your clock is also
determined by how far you are from the epoch. I'd rather have a
consistent precision over the entire representable range than be able
to measure picoseconds close to the epoch, but have the precision drop
by a factor of two every now and then.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:c9**********@oravannahka.helsinki.fi... 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?
Some folks are insecure, and thus greatly fear
competition. I welcome it.
-Mike
"rossum" <ro******@coldmail.com> wrote in message
news:46********************************@4ax.com... On 27 May 2004 21:27:14 GMT, go***********@burditt.org (Gordon
Burditt) wrote:
[snip]
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.
Gordon L. Burditt
< mode = nitpick >
Not quite accurate. We know precisely when the universe started; at
time = 0.
But only for relatively small values of zero.
The problem is that we don't know what the time is now.
< mode = whatever_passes_for_normal >
Thursday, about tea time. Always.
--
Mabden
"Jeff Schwab" <je******@comcast.net> wrote in message
news:k-********************@comcast.com...
I hereby nominate Bell Labs as the relative center of time, hence forth
referred to as the Origin.
I already pay them for "overages" on my cell phone. Please, don't ask me to
pay them on my LIFE, as well.
--
Mabden
"Corey Murtagh" <em***@slingshot.no.uce> wrote in message
news:10**************@radsrv1.tranzpeer.net... AngleWyrm wrote:
<snip> 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.
Last time I heard a prediction on that (which wasn't all that recent,
admittedly), trend analysis on usage vs known (or suspected) supplies
put the run-out point around 2025.
So yeah, I think a /lot/ of folks here will see the end.
My solution is that I plan to be dead around 2040 or so.
15 years after the oil runs out and we're all paying US$20/gallon for
vehicle grade alcohol :>
Yeah, there's always methane and grain alcohol - too expensive now, but
cheap when the oil runs out and costs $200 a barrel.
Those people will be livid with us, you know! They are going to have a space
station and off world places to go to. They'll really need rocket fuel and
have great ways of turning crude oil into fantastic new fuels with great
efficiency. They'll have cars running on corn (like we could now). But they
won't have the prime crude oil! They'll be boiling shale to eke out tiny
amounts of oil!
They'll look back and curse us for using all the primo stuff on CARS and
PLANES!!! It'll be, like, "You IDIOTS! You could have just burned Vodka and
gotten around on Earth! We need the good stuff NOW!!!!"
HeHe The future sucks!
--
Mabden
Alan Balmer <al******@att.net> wrote: On 27 May 2004 17:03:29 GMT, Joona I Palaste <pa*****@cc.helsinki.fi>
wrote:
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, 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?
The only reason it didn't happen was because we fixed it.
No, the reason _those_ did not happen is because coffee makers and spark
plugs don't stop working on 1-1-1900. The reason _normal_ computers
didn't stop working is because we fixed them (and usually well before
the goverment and scare media got their wits around the problem at all),
but the panic in "the press" was about much more than just normal
computers which actually use dates. FFS, people were selling
"Y2K-compatible" printer cables!
I suppose the world would have appreciated it more if we'd let
everything go to hell and then became heroes by fixing it afterward.
Now there I can't help but agree with you.
Richard us****@sta.samsung.com (Generic Usenet Account) 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.
I see a two-step solution, doing one thing and refraining from doing
another. Step one: start using 64-bit time_t's. Step two: stop storing
time_t's directly on disk, use standardised (ISO) formats.
Times and dates presented to your user need not change at all, since
presenting a user with an undecoded time_t is cruel and unusual
punishment anyway; therefore, there are none of the socio-behavioural
problems that surrounded the Y2K problem.
Richard
On 28 May 2004 04:15:10 GMT,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
I am quite sure I've heard stories about everything having an
electronic timer stopping working in 2000.
I'm sure these stories didn't come from the professionals who knew
what they were talking about. Besides, the problem is just a small
subset of a bigger issue, namely the maximum number that can be stored
in a given variable. It could for exmple be an old cash register which
didn't allow prices above 10 dollars for example. Or fuel pumps which
got into trouble when the fuel price went above 1.00. Or accounting
programs which gets into trouble when turnover reaches one million,
or 10 million. Or the position argument you give to the fseek()
function, now when files greater than 2Gig is a real posibility.
Villy This thread has been closed and replies have been disabled. Please start a new discussion. |
