As I recall, most Y2K remediation involved time patching. Interpreting a 2-digit year as probabably 19xx or 20xx. And that if that code wasn't replaced by 2037 or 2042, or something, that miscalculations could occur.

I recall there were 2 years involved, my vague recall is that they were 2037 and 2042, but I'm not sure.

Can someone clarify this for me? And confirm or correct my understanding. Thanks!

-- Jan Nickerson (JaNickrson@aol.com), January 31, 2001

Answers

Jan, that to which you are referring is
a process called windowing. Instead of
rewriting the whole code to use 4-digit
dates, they put in a patch that would
turn 2-digit dates to 4-digit dates by
using a window, i.e., 1938-2037. Any
2-digit date encountered would then fall
into this window. There is no standard as
to where this window should be so you
will find many different dates that are
used.

Here is a link for more information.
Windowing could make Y2K linger

-- spider (spider0@usa.net), January 31, 2001.

Spider, Windowing - that's exactly what I'm talking about.

Does anyone have a sense for how extensively windowing was used?

And if it was used as much as I suspect it was, is anyone aware of any IT programs underway to replace windowing with a longer term fix, or are ostrich heads just stuck deeper in the sand, relying on future generations to deal with the mess?

-- Jan Nickerson (JaNickrson@aol.com), January 31, 2001.

There have been a few threads on this over at the EZ Board, but darned if I know how they're archived. One particular instance where you could MAYBE make a legitimate inference that windowing was employed to remediate would be the Norwegian state-run railway system, which went on the fritz precisely at midnight December 31, 2000 (i.e. about a month ago) and caused all the trains in the system to be "side-tracked".

This was interesting obviously becuase of the tell-tail timing, and especially because the same railway system was having repeated railway accidents early in 2000 -- maybe even late in 1999, where railway switches failed to function. Thus, there is evidence (well, it's ALMOST evidence!) that would suggest they were having siginificant programming / embedded systems difficulties during the rollover. Although I have no programming or computer training, I'd surmise they eventually "solved" their problem by windowing, and this "solution" enabled the system to operate another year.

I'm also curious if there's any OTHER reasons why Moneky Wards closed up right after New Years. ????

-- Squirrel Hunter (nuts@upinacellrelay.tower), January 31, 2001.

oops. just saw the above thread.

-- (nust@upina.cellrelaytower), January 31, 2001.

The Windowing Issue

Whether or not an entity uses windowing does not absolve the entity from addressing the above two issues first. IT IS IMPORTANT FOR ALL ENTITIES TO UNDERSTAND HOW AND WHEN THEIR TRADING PARTNERS ARE MODIFYING DATA EXCHANGES DUE TO Y2K ACTIVITY. IT DOESN'T MATTER WHETHER WINDOWING IS USED, THE DATA EXCHANGES MUST STILL BE AGREED UPON. The best way to reinforce this point is to state that most of HCFA's shared systems, FISS, EDS, GTE, CWF, and UHC are using windowing internally in their processes, even though HCFA is requiring 8 digit dates in exchanges. The Medicare contractors decided this was the fastest and least expensive way to achieve Y2K compliance on time. And, they were right. But, a key problem with windowing is the need to establish a "pivot year", which is used in examining a 2 digit year to determine what the 4 digit year should be. For example, I believe CWF is using a pivot year of 17. So, when CWF encounters a 2 digit year of 16 (or anything less than or equal to17), it assumes the 4 digit year would be 2016. If it encounters 18 (or anything greater than 17), it assumes the year is 1918.

For data exchange purposes, when a 2 digit year is passed, it is important for the data exchangers to know what pivot year will be used to process that 2 digit year. Using the example above, if entity A generated a 2 digit year of 16, but was using a pivot year of 15, they may mean for the 2 digit year to represent 1916, not 2016. Yet, if the receiving system used the pivot year of 17, they would process the date as 2016. So, it's important for data exchangers who are passing 2 digit years, or 6 digit dates as cited at the Los Angeles conference, to agree on their data exchange and understand each other's windowing rules.

For exchanges of 8 digit dates, knowing the windowing rules is not as crucial. There is no assumption to be made when a 4 digit year is exchanged. The 4 digit year is what it represents. WE required Medicare systems to react to the 4 digit year as submitted. So, even though several of our standard shared systems and the CWF are using windowing internally and are using different pivot years, they are still required to exchange 8 digit dates to simplify the data exchange. There is no need for FISS to know what CWF's pivot year is, because when it sends a year of 2018, it should be processed as 2018 by CWF, regardless of CWF's pivot year. Instead, it is up to CWF to understand the 4 digit year and bridge it accordingly into its windowing processes.

The bottom line is that windowing is probably the fastest solution on Y2K, especially for those who started late. Also, windowing was adopted early on by EDS as a corporate approach to Y2K. So, states that started late or states that use EDS as a fiscal agent are likely to use windowing. It is important, however, especially where the data exchanges remained in 6 digit format for such entities to clearly and effectively communicate data exchange rules to their partners and to gain buy-in for those rules.

Addendum: Presumably, for cases in which the submitter is telling the provider to "do nothing", the submitter is giving the provider software to react to the "00" when the remit advice and other transactions arrive back at the provider site. In cases where the billing agent does not write the software for the provider shop or does not provide a terminal-to-data base relationship, it is unclear how the provider will be able to cope with data with the year 2000 and beyond. The provider has "side-stepped" the requirement, but has not enabled herself to handle year 2000 and beyond transactions. The "00" still compares low (early) to "99" whereas the correct year "2000" compares high (later) to "1999". Unfortunately, the programs will probably not "blow up" in this case, but run on, with unpredictable results.

http://www.hcfa.gov/y2k/ttesting/e2e-joe.ht

Asked by Martin Thompson (mthom1927@aol.com) from 205.188.195.22 on January 17, 2000

-- Martin Thompson (mthom1927@aol.com), January 31, 2001.

above at:

http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=002LV4

-- Martin Thompson (mthom1927@aol.com), January 31, 2001.

Martin,

Thanks for adding this nuance - I hadn't considered it before.

And I think you raise a really good point about "programs will probably not "blow up" in this case, but run on, with unpredictable results"

Thanks again for your speedy and thorough response

-- Jan Nickerson (JaNickrson@aol.com), January 31, 2001.