As Alan points out, it looks like silly season will be in full swing. Here
is a site claiming it will check the top web sites in the world, and if 5%
aren't responding at 1 minute before midnight (pick your time zone) a major
disaster has happened.
As has been pointed out before, many sites plan to shutdown their web sites or
disconnect from the Internet over the New Year's weekend. Which I guess is
a self-fulling prediction. The Internet is still considered an "extra" and
not a necessary connection like the telephone or ATM. I haven't heard anyone
suggesting they would turn off their ATMs, even though they are Y2K ready, just
to be safe.
Hmm, may be, _Let's GOD keep us out of such checkers, and our troubles will be
not more than our problems_ -:)? Just as I predicted - the Y2K danger is in
the
paranoia, not in the Y2K itself...
(I know ISP who did nothing about Y2K. Nothing yet. It results to the short /1 -
2 days/ delay in the January billing, and short /1 - 5 days/ some on-line forms
/statistic etc/ inavailability. And that's all. No one in this ISP will note
just the new year monent. And I believe a lot of other ISP are in the same
situation. Even if you do NOTHING you do not risk to lost service, yoiu risk to
lost billing and some on-line services /ticket reservation, accounting requests,
etc/, not more., Ansient, Cisco Terminal Server issued in the 1990 year is Y2K
compilant - in the terms of functionality; any such box is Y2K compilant. If
some crazy, crazy box is uncompilant at all and stop running in the very moment
of new year /I hardly know how to program such crazy box - you should use Year
as the primary date source/
it can be easily fixed by installation another (wrong) date into it.
But reading about this testers, watchers etc I really aware of Y2K problem - if
all of this paranoyiks install additional network systems and create additional
traffic, and million of paranoyiks type in WWW requests in the very moment of
new
year just to check if they are alive yet or already not - they, people, not
soft/hard/ware - could cause real, REAL disaster. -
PS. Btw, do you remember the date of 2035 year when UNIX systems can face the
REAL time problem? -
Wasting an entire 2 billion seconds to check for a -1 error condition
instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But
it would break a lot of userland programs to change. As far as I know in
BSD it is still a signed long, at least in machine/ansi.h.
Or February 6, 2106 at 6:28:14 if your UNIX system keeps an unsigned 32-bit
time_t. I Y2.038k tested my Solaris 7 box, it kept time past 3:14 AM 1/19/38,
but the date command would not set it. Which implies that the kernel itself is
unsigned, while the date command uses a signed number.
Wasting an entire 2 billion seconds to check for a -1 error condition
instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But
it would break a lot of userland programs to change. As far as I know in
BSD it is still a signed long, at least in machine/ansi.h.
it's not signed just so that you can check for a -1 error condition,
it's signed so that you can say time "a" - time "b" gives number of
seconds "c", where "c" may be positive or negative (ie, the difference
between two points in time is easily presentable). you may never have
used this particular functionality, but that's why it's there.
it's easy to say "just make it unsigned and you will win another 68
years!", but you have to consider *all* of the uses of a time_t.
the time in the (any) kernel is kept as signed so that it's in sync
with the rest of unix stuff. you can call it unsigned, since it will
(probably) never go back beyond 1970, but that's picking nits. as for
the kernel keeping time beyond 2038, it's just incrementing a kernel
variable. there's no check in any c code you write for integer
overflow...it just goes negative. try setting your clock to just
before the roll over, letting it roll over, and then touch a file and
see what ls says. or date. date probably just doesn't like to parse
things beyond that date.
it would be better, imho, to go to a 64 bit signed time_t, but that
would be a major flag day.
>
> Or February 6, 2106 at 6:28:14 if your UNIX system keeps an unsigned 32-bit
> time_t. I Y2.038k tested my Solaris 7 box, it kept time past 3:14 AM 1/19/38,
Folks, time_t is _SIGNET LONG_, not unsigned one. And y2.038k is really a
problem, and can touch some real-time systems (Y2K can not, except some
absolutelky crazy ones).
> but the date command would not set it. Which implies that the kernel itself is
> unsigned, while the date command uses a signed number.
Wasting an entire 2 billion seconds to check for a -1 error condition
instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But
it would break a lot of userland programs to change. As far as I know in
BSD it is still a signed long, at least in machine/ansi.h.
--
Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble
PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB)
AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA
"A mind is like a parachute, it works best when open." -- Unknown
Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/
[ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew Brown wrote: ]
Subject: Re: Silly season
it would be better, imho, to go to a 64 bit signed time_t, but that
would be a major flag day.
"would be"!?!?!
No, it *WILL* be an important day, but it will happen on a per-system
basis (and perhaps per-protocol basis if indeed there are any network
protocols carrying time_t or similar values).
Greg A. Woods
Sent: Thursday, December 23, 1999 11:28 AM
[ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew
Brown wrote: ]
> Subject: Re: Silly season
>
> it would be better, imho, to go to a 64 bit signed time_t, but that
> would be a major flag day.
"would be"!?!?!
No, it *WILL* be an important day, but it will happen on a per-system
basis (and perhaps per-protocol basis if indeed there are any network
protocols carrying time_t or similar values).
Those of us implementing 64-bit OS (Alpha, Merced, etc) get this as part of
the package. However, this does NOT correct databases that already have a
32-bit time_t (which shouldn't be the case, but is a good probability [lazy
coders]).
Ergo, even the fact that 90% of the computers will be 64-bit safe by 2038
won't save us. Stored data will have to be checked and the conversion will
obsolete many backup tapes. What I am saying is that there is still a
data-migration issue, just like Y2K. The problem is only transitive in
protocols and running code, there is not much inertia there, but the real
problem is data in long-term storage, where inertia is the name of the game.
Btw, an idea. Some of you are tsting their system as they will work in 2000
year. This means the installation of the future time, isn't it? Why don't just
tesh y2.038k too (it's not big difference how many different frauded dates to
test - one /1 January 2000/ or 2 (1 Jan and this, 2038 /which day it will be,
exactly?/ date).
And my suggestion is that y2038k will be a very serious problem for the
Unix-based systems and some network protocols, not as Y2K problem are.
I don't know how big of a deal is being made about 2.038K on a corporate
management level, but it would seem that the ensuing months would be just
about a perfect time to address this issue. After all, many companies have
teams for the date-field issue right now, and we've gotten pretty good in
the past couple of years at analyzing this problem. It would only make
sense to immediately move on to the 2038 work after Y2K settles down. Let's
just not wait until 2035 to deal with it this time, huh?
Y2K: We'll know in 9 days. We'll suffer for a bit afterward.
32bitbug: I think we'd best leave this one alone until somewhere
around 2020. By then I don't think most current system
kernels will be in use, and, well, I'll be retired.
it would be better, imho, to go to a 64 bit signed time_t, but that
would be a major flag day.
"would be"!?!?!
okay...will be. when it happens. i wasn't trying to imply that it
might not...i'm sure it will.
No, it *WILL* be an important day, but it will happen on a per-system
basis (and perhaps per-protocol basis if indeed there are any network
protocols carrying time_t or similar values).
um...like ntp? or the time protocol as per rfc868, a slightly
adjusted (by 25567 days...gee has this expired already? time_t
(well...okay, "a 32 bit binary number") protocol.
fwiw - even if you're on a 64 bit system, any time_t you *expose* to
the outside world is going to be converted to the 32 bit flavor. so
you might be able to continue after 2038, but you'd probably be rather
alone in it.
Y2K: We'll know in 9 days. We'll suffer for a bit afterward.
yep.
32bitbug: I think we'd best leave this one alone until somewhere
around 2020. By then I don't think most current system
kernels will be in use, and, well, I'll be retired.
well...you could come out of retirement and fix all the systems, kinda
like the cobol and fortran programmers in the sixties who thought no
one would still be using their code any more after 30 years...look who
was wrong?
Do you honestly believe that corporate *name your country* will spend the
money NOW to fix a problem that won't affect them for 30+ years? One of us
is living in a fantasy world....
Think about it this way. Would you rather the Y2K preperation "we must
test our wall clocks for Y2K then fill out 20lbs of paperwork and affix a
Y2K certified sticker" weenies found immediate employement, or would you
rather see them go back to their go-pher my coffee jobs for the next 37
years?
