Re: Short sighted coding

From           kiyoinc@ibm.net (cory hamasaki)
Date           13 Jul 97 23:31:58 GMT
Newsgroups     comp.software.year-2000

In <5qa8k2$24fc@janus.la.platsol.com>, aardvark@janus.la.platsol.com (Warren Usui) writes:
>In article <33C4F751.55A9@edwardjones.com>,
>Eric Buckley  <Eric.NoSpam.Buckley@edwardjones.com> wrote:
>>We're finding problems in *Java*
>>code. This stuff is less than a year old! Perl, C++, Smalltalk, VB, I
>>could go on but you get the idea. 
>
>Java's util package has a Date class that uses years since 1900 as a year
>value.  Both Eric and I have posted separate C bugs involving tm_year.  Any
>bug that exists involving the tm_year value in C could also exist in Java
>as well.
>
>
>2. My experience has mostly been limited to UNIX and some NT work.  
>   I can't even spell some of the acronyms Cory uses.  It's not the
>   fact that I see Year-2000 bugs that bothers me.  What bothers me is that
>   much code I deal with does not use year fields, and I've already seen more 
>   than my share of Year-2000 bugs.  I know what it's like from my foxhole,
>   and I am nowhere near the front-lines in the Year-2000 battle.
>  

Warren, Eric, you geeks (and I use that term with great respect) 
are in the middle of the war.  While the Unix infrastructure is 
nothing like MVS; there are lots of meta-systems riding on Unix 
hubs.

MVS might be like the dynamos at Niagra Falls, but Unix is 
keeping the dynamos oiled and is regulating the speed.

It's all connected, it's all interdependent and when the clock 
counts down, all the pieces of the infrastucture are at risk.

I'm very ignorant of Unix, I can't spell IPCS, IPCRM MSG, SU, but
I can crank C/C++ and my geekette pal, the 30 year old kid who 
drags down $120K+/year, has been telling me about tm underscore 
year and how she's played with rolling the clock forward and 
watched different applications that use tm underscore year blow 
themselves appart.

At her urging, I've looked at the tm struct in OS/2 CSet++ and 
it's exactly the same.  This is a C artifact and any system built
on C that uses dates is at risk.  To be accurate, if the 
applications code is written exactly to the spec in the MAN 
pages, it will pass Y2K but as the geekette says, how many people
made the distinction between YY and years since 1900.  How many 
are prepared for 100 = 2000?   In 1990, YY and years since 1900
are both 90.  In 2000, YY = 00 and years since 1900 = 100.

What's even worse, the 'live for today' gang at IBM have even
stranger things in store for us.  I'm talking about SVC-11 and 
the PL/I resident DATE() function.

Did any of you think it would be this much fun?

Cory Hamasaki