Re: Year 2000 Solutions Conference

In article <4bf8m7$82h@panix2.panix.com> ro@panix.com (r l reid) writes: >In <4bet0v$ak1@grid.direct.ca> emvy@platon.com (Maarten Veerman) writes: > >>In article <uspdi-2112951633250001@uspdi.clark.net>, uspdi@clark.net says... > >>GIVE IT A FUCKING REST, ASSHOLE! > >>> The Year 2000 date problem is coming up fast, and you need a solution. >>>To stay ahead of the problem you need to attend the > >Had a little too much coffee, Maarten? Sounds like you could use a vacation. >It is a very real problem in the real world, where sometimes old design >decisions stop making sense. > >I'm well aquainted with an accounting system created 25 years ago, when >disk space was real expenseive. Since every single record had at least >one date, saving 2 bytes per date was significant. > >Also, we had memeory restrictions on those 11/70's, and we would tune >code to make the data and program space as small as possible. > >So the redundant "19" was ditched. > >After all who ever heard of a system having a life cycle that long? >The designers expected it to last 7 - 12 years. > Yes, maybe. *I* was around then, too, just starting out. We used CYBER hardware and it cost $60K plus for a hard drive. But we had paper data going back to the 1800s and knew it would still be in use in the 21st C. We used 4 year dates. Every program I have had input to has used 4 year dates. Even then, disk was cheaper than good programmers. I think we still have a few 11/70's in our back shed and I know programmers were more expensive than those DEC boxes. There are a lot of programs and users who are going to pay for the lack of foresight in not keeping 4 year dates to save a couple bytes. Those of us who did see this coming over 20 years ago are entitled to say "give it a rest". It's a non-problem. Merry Christmas. Peter Wiley