Thread View: can.org.cips
1 messages
1 total messages
Started by Bill Ross
Fri, 19 Mar 1999 00:00
Re: MOST Y2K FIXES WILL ONLY LAST A GENERATION
Author: Bill Ross
Date: Fri, 19 Mar 1999 00:00
Date: Fri, 19 Mar 1999 00:00
150 lines
5964 bytes
5964 bytes
Charlie, you're right; but not all purchased software handles the situation as you describe. In the specific case I talked about the keyed input must exactly match the stored information, because the (purchased) application won't handle any fuzziness. Regards, Bill Ross C & L Whitfield <mlw@soonet.ca> on 03/19/99 07:51:10 AM Please respond to CIPS General Discussion List <CIPS-L@LISTSERV.UNB.CA> To: CIPS-L@LISTSERV.UNB.CA cc: (bcc: Bill Ross/CTAL/CTC) Subject: Re: MOST Y2K FIXES WILL ONLY LAST A GENERATION Bill - I may be wrong in my assumption but I have a concern with your statement that the "staff liked it because it saved 2 keystrokes". This is I think one of the most misunderstood concepts around the 4 digit year and century rollover. Namely, as long as the underlying data base and logic can deal with the rollover there is ABSOLUTELY no reason in many cases to either enter or display anything more than 2 digits. It is only when the system is dealing with data that spans a period in excess of 100 years where that is even an issue. I have been continully frustrated by the passion of Y2K "fixer uppers" to clutter up screens and printouts with the century information when it added nothing to the value of the display -- For example if your drivers licence shows an expiry date of 01-05-30 you will (assuming you understand the yy-mm-dd format) correctly interpret this as May 30, 2001. > > >James: > >I don't know if it's true for "most" solutions, but there are operating >systems that use "windowing" to deal with 2 digit years; and it's quite >likely that there are people out there who said, "Great! We don't have to >worry about changing files and DB's to 4 digit years". > >I recently managed an imaging project that stored customer statement images >so that call centre reps could view them when handling customer calls. The >application was based on an IBM AS/400, which uses a "pivot date" of 75 to >handle 2 digit dates. If the date is 75 or greater, it's assumed to be the >current century; and if it's less than 75 it's assumed to be the next >century. This is not a shortcoming of either the AS/400 platform or the >imaging application, both of which handle 4 digit years satisfactorily; but >of the (outsourced) facility from whence came the input, who put a 2 digit >year in the date field used to index the archives. Despite my >recommendations to have the supplier change the field to 4 digits, my >client decided to leave it "as was", since it had no negative long term >effects. In fact, their call centre staff liked it because it saved them 2 >keystrokes on most calls. > >Heaven forbid they would still be using it 100 years from now, but I >believe this facility would handle the rollover from 2099 to 2100 without >modification. > >This solution is OK for some applications, such as the one described above >where there is no sorting and no calculations involving dates; but it's >short-sighted for any application that does involve those activities. > >Regards, > >Bill Ross > > > > > > >James Crooks <jcrooks@vse.ca> on 03/18/99 07:42:41 AM > >Please respond to CIPS General Discussion List <CIPS-L@LISTSERV.UNB.CA> > >To: CIPS-L@LISTSERV.UNB.CA >cc: (bcc: Bill Ross/CTAL/CTC) >Subject: MOST Y2K FIXES WILL ONLY LAST A GENERATION > > > > >Is this article's statement true for most Canadian Y2K remediation >efforts? >Sort of like the national debt, shove it under the rug and let the next >generation worry about it. >/jc >-------- Original Message -------- >Date: Wed, 17 Mar 1999 02:13:07 -0800 >From: "Mark Gibbs" <mgibbs@gibbs.com> >Reply-To: ibg-list@silcom.com >To: "IBG" <ibg-list@silcom.com> >MOST Y2K FIXES WILL ONLY LAST A GENERATION >The fix used to patch 80% of the worlds' computers to avert a Y2K crisis >is >actually only a short-term remedy called "windowing." Rather than using >a >permanent fix called "expansion," which requires transforming all >two-digit >year-dates found in software into four-digit year-dates, the "windowing" >patch is a trick that forces software to "guess" whether dates fall in >the >1900s or the 2000s; typically, lower numbers (perhaps up to 30) will >belong >to the new century, whereas higher numbers (such as 87) will belong to >the >old century. Although many experts say this is the only practical way >to >solve the problem, others are warning that the "windowing" approach is >just >pushing the problem under the rug for awhile. Keith Rhodes of the >General >Accounting Office says, "It's like the Fram oil filter guy: You can pay >me >now or you can pay me later. It's not solving your problem. It's >delaying >the inevitable." >(San Jose Mercury News 15 Mar 99) >Humm. So, do you care what happens after you've left the company -- oh, >let's say you're in your thirties -- some 60 or 70 years >later? >Gibbs, over ... >================================================= >Mark Gibbs Gibbs & Co. http://www.gibbs.com >Tel: 805-643-4999 Fax: 805-641-3311 >================================================= > > > > >======================================== >The Intranet Business Group is sponsored >by Network World's IntraNet Magazine >Admin and queries: ibg-admin@gibbs.com >======================================== > >Attachment Converted: C:\INCOMING\smime2.p7s >
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads