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

[q]

Not only must the year be divisible by 4, if it is a century
year it must be divisible by 400.

Robert W. McAdams wrote:

"T.M. Sommers" <tm*@nj.net> wrote in message news:<0q******* *************@t elcove.net>...

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.

Actually, the next big date problem is the Y2100 problem (at least for
those who aren't still concerned about Y2K, which is still 44 years
away). Many programs still assume that any year that's evenly
divisible by 4 is a leap year.
Bob McAdams
Fambright

[Bob Day]

"Gerry Quinn" <ge****@DELETET HISindigo.ie> wrote in message
news:MP******** *************** *@news.indigo.i e...

In article <nZ************ *****@nwrdny03. gnilink.net>,
xx*****@yyyyyyy .com says...

"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.

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

"Only the vigilance of our firefighters has prevented this 2000-year old
forest from burning to the ground dozens of times over the last decade!"

- Gerry Quinn

Pull your head out of the sand for a moment, and take
a look at: http://www.grantjeffrey.com/article/y2kretro.htm

-- Bob Day

[Dan Pop]

In <c9********@lib rary2.airnews.n et> go***********@b urditt.org (Gordon Burditt) writes:

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.

Does it matter?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Leor Zolman]

On Thu, 27 May 2004 11:41:50 -0700, Alan Balmer <al******@att.n et> wrote:

On 27 May 2004 17:03:29 GMT, Joona I Palaste <pa*****@cc.hel sinki.fi>
wrote:

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? 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 suspect just the opposite. In the ensuing uproar over renegade,
unprincipled, greedy software developers, government would just enact the
Federal Software Quality Commission to oversee and regulate the software
industry into submission.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Dan Pop]

In <c9*********@gr apevine.wam.umd .edu> "myren, lord" <th******@wam.u md.edu> writes:

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. ;)

Yeah, but that would be a 64-bit x 4 vector processor ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

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

In article <nZ************ *****@nwrdny03. gnilink.net>,
xx*****@yyyyyy y.com says...

"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.

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

A country generating no significant software products has nothing to fix.
It's as simple as that.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Stephen Sprunk]

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

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. ... Or accounting programs which gets into trouble
when turnover reaches one million, or 10 million.

The first company I worked at was acquired for cash, and they paid out our
stock options as a cash bonus through payroll. Our CEO's share was $250M,
which unfortunately crashed the payroll system every time they tried
printing the checks. We ended up having to get a custom patch from the
software vendor, and this delayed the payout (and acquisition) over a
month...

Certainly a much more interesting anecdote than anything I heard about Y2k
:)

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]

"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.

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.

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

[Leor Zolman]

On 27 May 2004 21:27:14 GMT, go***********@b urditt.org (Gordon Burditt)
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.
That's ok, we probably know it to at least the same relative accuracy as
January 1, 1970 "accurately " mirrors the beginning of the Unix era.
-leor


Gordon L. Burditt

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[xarax]

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

On 28 May 2004 04:15:10 GMT,
Joona I Palaste <pa*****@cc.hel sinki.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.

Back around 1983 at Southern California Edison, there was
a panic in their mainframe data center. SCE printed their
paychecks, as well as managing all of their accounting on
their own IBM mainframe system (using COBOL). The paychecks
were printed monthly. The panic happened when some executives
were seeing asterisks appearing in their paychecks. It turns
out that the COBOL programmers never imagined the possibility
of someone getting a monthly paycheck for more than $9,999.99
and when that finally happened, the dollar amount appeared
as **,****.** and invalidated the paychecks.

In another typical COBOL moment of ineptitude, the programmers
were discussing/debating the merits of a possible stock split
(they were participating in the SCE employee stock purchase
plan). The crux of the problem was that the COBOL programmers
were afraid to vote for the stock split, because they had
HARD-CODED the number of outstanding stock shares in about a
zillion COBOL programs and they didn't want to give themselves
more work to go back and change all of that source code by
splitting the stock.

Another COBOL moment at SCE: They used variable-length records
to indicate the record variant data type. For example, if the
record was 60 bytes long, it was type "A". If it was 70
bytes long, it was type "B", and so on. Then a situation
arose where they needed to define a new record type, but
it was the same length as an existing record type. They
had already hard-coded the record lengths in zillions of
COBOL modules. The solution? Insert padding fields to make
the new record an arbitarily longer length than the existing
record types. Then go into every module that had the hard-coded
record lengths and add the new record length/type.

Ah, the good ol' days...