I'm surprised that I haven't seen anywhere this idea regarding the "Joanne Effect." If an organization's fiscal year runs from Jan. 1 1999 to Jan. 1 2000, why not shorten it to end on Dec.31? If it's April to April or even July to July, etc, an organization could still end on Dec. 31 1999. True, cost projections, etc, will be screwed up, but at least that would buy some time.

Any thoughts on why this would or would not work, or why no-one else seems to have suggested this on any of the forums or ng's?

-- pshannon (pshannon@inch.com), September 28, 1998

Answers

pshannon,

From what I've read on the csy2k newsgroup is that the scariest part of the "Jo Anne (Slaven) Effect" is that it is a relatively recent discovery. What the realization really did was shorten the time line for remediation of code in mainframe computers and I think the effects have already become reality. In other words, those companies that know about the effects still face the problem but are out of time to fix it, and many more have no clue.

You can go to dejanews.com and do a search for more informat

-- Michael Taylor (mtdesign3@aol.com), September 28, 1998.

pshannon, this would work......but it also would enscrew normal remediation. Now you'd have to stop the normal work and implement a fix for just the 'Jo Anne Effect' problems, which would put the rest of the Y2K problems behind even more than they are.

Most 'Jo Anne Effect' problems won't be devestating, and most will get caught pretty easily. They'll be a pain in the behind though, because they will draw attention away from fixing the more devestating problems.

So, it's a no-win situation.

-- rocky knolls (rknolls@hotmail.com), September 28, 1998.

Taxes and the fed's and stock market type regulations would kill you.

Exact, specific adherence to standard rules are essential to bookeepers and the financial types, even though the rest of us might not like it, they pay the bills, and have very strict requirements at the legal level about changing fiscal years.

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), September 28, 1998.

As bob Cook points out, the fiscal year rules are SO tight, you can't just "Change it" when you want to. There are rules about when you can announce this, how different it can be, and how it gets implemented, and when. In some cases, the rollover gets split! (If i remember my corp finance aright)

CR

-- Chuck a Night Driver (rienzoo@en.com), September 29, 1998.

Short answer: no, that would not work.

Long answer:

The effect results from code, in any given language, that looks at an entered date (from user input, or a scanned form, or data received electronically from some source), which we'll call "THIS HERE DATE," and makes some decision, according to a formula like this:

"Hmm, is THIS HERE DATE in the year BEFORE THE CURRENT YEAR? or in the year THAT IS THE CURRENT YEAR? or in the year AFTER THE CURRENT YEAR?"

The Jo Anne Effect happens when A) a program tries to answer the above question by dealing solely with 2-digit numbers, and 2) the current year unfortunately happens to be 1999.

Then the year "AFTER THE CURRENT YEAR" is either 00 or undefined or Something Wicked--no way to tell, it depends on the language and the program.

So "THIS DATE" can be anything from 1/1/1999 to 12/31/1999 and still cause the problem.

Your proposed solution would mean changing the logic involved in calculating "AFTER THE CURRENT YEAR" so that it says something like "BEFORE OR EQUAL TO THE LAST DAY OF THE CURRENT YEAR."

Setting aside all of the regulatory and other concerns others have raised, that would be fine.

BUT--this solution requires that you locate and change the relevant code in every instance where it occurs. It's not just a business decision, it involves programming changes.

AND--if you've located every instance where this problem occurs, you could just (or almost) as easily make the code "00-compliant" in these locations.

Either way, it's an easy change. The PROBLEM is finding, within gazillions of lines of code, all the places where this pattern of date comparison occurs.

Note for the uninitiated, this is the same situation as with Y2K remediation in general: a noncompliant line of code, or subroutine, or even module, is really simple to fix, once you shove it in my face.

"Here's your rag and polish; polish every needle in this haystack."

Trivial, yet impossible.

Down all the days, --StaggerNation

-- StaggerNation (no@not.quite), September 29, 1998.