🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

1 total messages Started by Bill Ross Fri, 19 Mar 1999 00:00
Re: MOST Y2K FIXES WILL ONLY LAST A GENERATION
#112
Author: Bill Ross
Date: Fri, 19 Mar 1999 00:00
150 lines
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