The Year 2038 Problem

[Generic Usenet Account]

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

[j.j.haak]

Op Fri, 28 May 2004 08:26:05 GMT schreef "Mabden"
<ma****@sbcglob al.net>:

<snip>

But perhaps we could just send a few Christians over and get them all to
convert to Jesus Time (r).

Why do you think we live in the year 2004 Anno Domini?

Coos

[jpd]

On 2004-05-28, Stephen Sprunk <st*****@sprunk .org> wrote:

"Corey Murtagh" <em***@slingsho t.no.uce> wrote in message
news:10******** ******@radsrv1. tranzpeer.net.. .

AngleWyrm wrote:

> My solution is that I plan to be dead around 2040 or so.

Hm I might not make that. Fun prospect!

15 years after the oil runs out and we're all paying US$20/gallon for
vehicle grade alcohol :>

I assume that $20 is after inflation, which means it'll be on par (in
constant dollars) with what we pay for petrol or ethanol today. Hardly a
problem, though I'd expect us all to be running on hydrogen by then; ethanol
is a transition fuel.

The fun thing of course is that alcohols are about the simplest things
to make, and dead cheap too. The only thing that make them so darn
expensive is the various governements wanting a piece of the action, in
the interest of letting people have less fun for their dollar.

Fact is, oil is not as cheap as it seems, as it has rather high cleanup
costs associated with it. Same with nuclear fuels, but oil doesn't have
quite such spectacular faillure modes. Altough I have to admit that
fuel/air bombs are kinda neat. And oily birds make for nice television
and cause traffic jams with people driving to a different, clean beach.

Same with our silicon based computing stuffs. They and the facilities
needed to produce them are not very environment friendly, and the
pittance some of us now have to pay as advance clean-up costs will not
be enough to fix the problems the obsoleted debris will create later on.

Anyway. Whatever we do, we'll pay for it sooner or later. If sufficiently
late we'll just be cursed by our ancestors. Which would you prefer?
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .

[Gordon Burditt]

>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 think I also saw "Y2K-compatible" printer *PAPER* advertised in
stores.

There were a few stores around December 1999 that started refusing
non-Y2K-compatible checks (Those with 19__ pre-printed on them).
They eventually relented to the extent that you were allowed to
cross out the 19__ and handwrite in a full 4-digit year. But if
any part of the date was handwritten, it *ALL* had to be handwritten.
No writing in "19" or "20" in front of a 2-digit year on computer-printed
checks. Some employees at that store were grumbling that their
paychecks still had 2-digit years on them.

There were a bunch of ads for "Y2K-compatible" watches. Most of
those watches were really old and didn't even indicate the day of
the week or the day of the month, much less the year. But they
WERE "Y2K-compatible"! Somebody even tried to make watches Y2K
compatible by sticking tape over the month and the year display,
and charge double for that.

The watch I am wearing now (uses a battery, but the display is good
old-fashioned hands pointing at numbers on a clockface, no LED,
LCD, or anything like that) indicates the day of the month and the
day of the year, but you can't set the month or the year, and at
the end of any month shorter than 31 days you have to reset it. I
did make sure to change the battery in it before the year 2000, on
the possibility that I might have trouble getting one later (a
problem which never materialized) plus it was getting weak anyway.

Gordon L. Burditt

[Michael Wojcik]

In article <c9**********@o ravannahka.hels inki.fi>, Joona I Palaste <pa*****@cc.hel sinki.fi> writes:

http://www.rinkworks.com/stupid/cs_y2k.shtml

Many stupid people making many stupid claims about a topic does not
mean the topic itself is stupid.

Really, Joona, I'm tempted to invoke Pop's Instruction here. I can't
think of a single subject of significance for which there *aren't* a
bunch of ignorant misconceptions. These anecdotes demonstrate
nothing whatsoever about the Y2K problem and its remediation, and I
can't for the world imagine why you would believe otherwise.

Either you participated in Y2K problem investigation and/or remediation,
and therefore know something about it, or you did not and do not.

--
Michael Wojcik mi************@ microfocus.com

Is it any wonder the world's gone insane, with information come to be
the only real medium of exchange? -- Thomas Pynchon

[Michael Wojcik]

[Snipped most of the newsgroups, as this troll thread was ridiculously
crossposted.]

In article <MP************ ************@ne ws.indigo.ie>, Gerry Quinn <ge****@DELETET HISindigo.ie> writes:

"Gerry Quinn" <ge****@DELETET HISindigo.ie> wrote in message

In countries where little or no effort was put into preventing it, no
significant problems occurred either.

There was a Feb 29 bug in 2000 that wasn't hyped at all, and little
enough went wrong that day either.

This is rather impressively arrogant even for you, Gerry.

I personally saw numerous major projects that identified and corrected
Y2K bugs (including Feb 29 2000 bugs, and other variants) in in-use
production code that would have caused major difficulty and expense
for its users, and I wasn't even involved in Micro Focus' Y2K remediation
business.

Do you have any evidence for either of the claims above?
Truth is the Millenium Bug Disaster was a '60s science fiction scenario,
The truth is that you're making unsubstantiated claims about a subject
you've demonstrated no actual knowledge of.
based on the assumption that all the operations that keep the industrial
world turning are done by technicians blindly obeying the orders on
punched cards that some big old computer spits out.
No, the actual assessment of the problem - not the myth reported by
an ignorant news industry - was based on actual examination of actual
running code.
The real world is
considerably more fault tolerant.

The real world runs a great deal of very fragile code. I've seen
quite a bit of it running at customer sites, and again that's just
incidental to my actual job. I rarely look at customer code, but
the bits I do see are not, in fact, particularly tolerant of faults.

A great deal of effort went into fixing real bugs in real code before
the rollover. It was a problem and it was handled. Those who claim
there was no problem are just as misinformed as those who hyped it
beforehand.

--
Michael Wojcik mi************@ microfocus.com

They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James

[Christian Bau]

In article <c9********@lib rary1.airnews.n et>,
go***********@b urditt.org (Gordon Burditt) wrote:

There were a bunch of ads for "Y2K-compatible" watches. Most of
those watches were really old and didn't even indicate the day of
the week or the day of the month, much less the year. But they
WERE "Y2K-compatible"! Somebody even tried to make watches Y2K
compatible by sticking tape over the month and the year display,
and charge double for that.

There is one company that proudly produces a very VERY expensive
non-Y2100 compatible watch. It is a mechanical watch, and displays year,
month, day and weekday correctly until March 1st 2100. At that time,
some part has to be replaced, but the replacement is already included in
the price when you buy it today.

[Mabden]

<j.******@hccne t.nl> wrote in message
news:lt******** *************** *********@4ax.c om...

Op Fri, 28 May 2004 08:26:05 GMT schreef "Mabden"
<ma****@sbcglob al.net>:

<snip>

But perhaps we could just send a few Christians over and get them all to
convert to Jesus Time (r).

Why do you think we live in the year 2004 Anno Domini?

Popes used to have too much control...?

People believe in fairy God fathers...?

The Chinese numbers were bigger than Christians could count...?

Counting things that are old is more fun using negative numbers...?

Them pesky Romans. I don't know why, but I bet it had something to do with
them pesky Romans...!

Abacus' were about to roll over, and everyone was panicking...?

And the number VII reason why we live in the year 2004AD:

God knows!

--
Mabden

[Stephen Sprunk]

"Joona I Palaste" <pa*****@cc.hel sinki.fi> wrote in message
news:c9******** **@oravannahka. helsinki.fi...

Bob Day <xx*****@yyyyyy y.com> scribbled the following
on comp.lang.c:

"Generic Usenet Account" <us****@sta.sam sung.com> wrote in message
news:90******** *************** **@posting.goog le.com...
< 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?

There were one or two specific model-years from a specific car manufacturer
that stopped working at the rollover (GMT). While I'm sure it was traumatic
for the people it happened to while driving, there had been recalls (free
fix) for those problems in place for half a decade. In any case, it was far
less than 1% of the vehicles on the road, which means it was a non-event
compared to all the media hype.

Unrelated anecdote:

In January 2000, I got an electric bill for the period X Dec 1999 to X Jan
1900, which I just laughed off since the amount billed was correct. A few
days later, I got a "corrected" bill for the period X Dec 2099 to X Jan
2000, with the same amount due. A week later I got yet another bill, this
time for the period X Dec 99 to X Dec 00, and again for the same amount. It
appears the programmers had hard-coded the century that was printed even
though the billing calculations were correctly done with modulo 100 math.
Gotta love COBOL.

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

[Stephen Sprunk]

"Villy Kruse" <ve*@station02. ohout.pharmapar tners.nl> wrote in message
news:slrncbdqbn .3m8.ve*@statio n02.ohout.pharm apartners.nl...

Besides, the problem is just a small
subset of a bigger issue, namely the maximum number that can be stored
in a given variable.

My favorite real world example is when the NASDAQ lost hundreds of thousands
of trades one day due to a fixed-length field in their protocol. It seems
they used a six-digit sequence number for transactions, and the first day
that counter rolled over (in the late 90s) the trading computers would
correctly process the trades but fail to record them anywhere. Fortunately
there was an ultra-paranoid person at some institution who insisted on
printing every trade as it came off the wire (before processing), so after
the necessary bug fixes were done the exchange and its brokers were later
able to re-enter all the data without customers finding out there'd been a
problem.

Every banking system has humans in the loop _somewhere_ in case something
goes wrong, whether it's from fraud or just software bugs. This is a large
part of why it still takes 7 to 14 days for a check to clear even if it's
from a bank across town -- they know better than to trust their programmers.

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

[Stephen Sprunk]

"Otto Wyss" <ot*******@orpa tec.ch> wrote in message
news:1geihnf.6q 45la7adlz4N%ot* ******@orpatec. ch...

Stephen Sprunk <st*****@sprunk .org> wrote:

"Otto Wyss" <ot*******@orpa tec.ch> wrote in message
news:1gegpbt.ot 7t0q1p5gqogN%ot *******@orpatec .ch...

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.

I don't hope time_t isn't as often converted to int as size_t is. Well I
guess it won't be that big problem, I just wanted to point out that you
never should assume what other coders think.

Neither time_t nor size_t is ever converted to int in code I write or
maintain; I can't speak to what others do...

With the growing adoption of 64-bit desktops we already see bugs where
people improperly convert size_t to int, at least on platforms where int
isn't also 64-bit (i.e. AMD64). We'll find out how many people don't use
time_t correctly in 2038 :)

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