I was reading the article on Microsoft's approach to remediation on Windows 95... http://www.zdnet.com/pcweek/stories/news/0,4153,1014262,00.html and noted the following comment re: windowing....

'Windowing adjusts how dates between 1935 and 2034 are rendered. Any two digit date after 35 is shown in the 1900's, while any before is shown as being in the year 2000...'

Using this technique my father-in-law's birth date (1904) would be changed to 2004...rendering him as yet unborn.

I am assuming that different applications (read: Social Security Admin.) use different formats for these windowing techniques. Is this indeed the case? and if so, doesn't this create just as big a mess when systems interact with one another and each has it's own special brand of windowing?

-- Shelia (Shelia@active-stream.com), April 05, 1999

Answers

Bingo....

-- RD. ->H (drherr@erols.com), April 05, 1999.

Sheila,

The simple fact is that the Y2K "problem" is nearly all current software using a 100 year window that closes on December 31, 1999. Since everyone with the "problem" is working with a "window" that will close at the same time, they all experience the results of that problem (whatever they may turn out to be) at the same time.

The "windowing fix" simply changes the dates that the "window" opens and/or closes. The problem that you have correctly identified is that there is no standard for the times, and everyone who uses the technique sets his own dates. There are two things wrong with this. First, it doesn't "fix" the Y2K problem, it simply turns it into a "Year 2035" problem (or whatever "closing" date is chosen). Second, since there is no standard "window", the results that you have noticed will cause other problems, such as when two systems with different "windows" exchange data. There are ways to deal with this of course, but it obviously makes a bad situation more complicated and simply puts things off until someone else has to deal with them (sound familiar?)

-- Hardliner (searcher@internet.com), April 05, 1999.

Not all dates are windowed. Social Security and anyone else storing date of birth uses the full 4 digit year or some equivalent representation (number of days since 1800). If you are running an inventory system and all dates are within ten years of the current date, windowing is a valid solution. It will require some maintenance down the road, but not on the scale of Y2K.

-- fran (fprevas@ccdonline.com), April 06, 1999.

Windowing has it's ups and downs for sure. Our technique uses a floating decade that will allow it to work through 2199. After that??? Birthdates are a problem as are the year built on some homes (we're finding out). We only store the 2-digit year online, but when you use a windowing technique for a birthdate in 1940 and a year built in 1950 and a loan maurity date of 2030 - it just don't work right. All 3 of those dates would end up in 2000.

Not really a biggie though, but a PIA none the less.

Deano

-- Deano (deano@luvthebeach.com), April 06, 1999.

Fran, I can not agree. It it's not on the same scale, why isn't the work being done now, instead of later? The biggest reason for windowing is to avoid expanding dates in EXISTING files. Once you expand a date field, you must recompile ALL programs that access that file, even if they don't use the date.

You do have a point with "sliding" windows. However, this requires additional logic, and will introduce more "fix" errors, and requires more detailed testing. I think the real answer is what percentage of programs in a system actually do date processing. If it's small, then the windowing quick fix is OK. Hovever, as the percentage goes up, at some point it's easier to just do it right, and expand the dates. Just my $.02 <:)=

-- Sysman (y2kboard@yahoo.com), April 06, 1999.

My confidence level re: remediation progress just took another dive. Has anyone seen any stats on how much windowing is being done?

-- Shelia (Shelia@active-stream.com), April 06, 1999.