Why does the fiscal year change of New York, Japan, etc. in April 1998 matter? Why do the problems potentially start in these cases before the year changes to "oo?"

-- Nathan Luft (Nate208900@aol.com), August 25, 1998

Answers

Nathan, the fiscal year of concern starts in April, 1999 (not 1998) in these places. It's of concern because many programs look ahead within that fiscal year. Since looking ahead takes them into 2000, there can be trouble.

This year those programs are only looking to March 31, 1999, so they don't see the year 2000.

Actually, there is a hypothesized effect--the Jo Anne effect, named for Jo Anne Slaven, who tossed it out on the table in the c.s.y2k newsgroup -- that should begin January 1, 1999. According to this hypothesis, accounting programs begin to look into the year 2000 on this date (or shortly thereafter), and will run into trouble. Is this accurate? I don't know, but if it is, expect problems to crop up in only a few months.

How severe will the 'Jo Anne effect' and the fiscal year effect be? Like the rest of Y2K, no one knows. It might be that the worst effect is that they will disrupt planned remediation. That is, unless the errors are remediated before the occurance dates, programmers might end up chasing the problems that are hitting on them now, rather than doing planned work. In other words, this would delay normal work.

-- rocky knolls (rknolls@hotmail.com), August 25, 1998.

I don't know what will happen to those organizations entering their y2k fiscal year in Aprill of 1999 but I understand that several state governments have 2 year budget cycles and a couple of them entered y2k fiscal year last July and so far the sky has not fallen.

-- Charles Michael (charliecmt@hotmail.com), August 26, 1998.

Sigh........

"The sky hasn't fallen."

Why does one make statements like that? Of course the sky hasn't fallen. What you've done is to take a rather trivial case (predictive programs) and announce that 'the sky hasn't fallen.'

The same could be said when financial institutions began to find problems in their 30 year mortgage computations a long time ago. Simple solution --- fix *those* lines of code. Small problem, easily done. The sky hasn't fallen.

By and large, budgetary programs that are predictive are not normal production programs. The difference is in the impact on company operation.

The following post by Cory Hamasaki explains things a little more clearly:

_______________________________________________________

"There had been speculation on what's the magic of Fiscal Year 1999, Fiscal Year 2000. Jo Anne, in a classic c.s.y2k post, explained that certain financial systems sort (in the sense of 'group' rather than 'collate') transactions into last year, this year, next year piles.

These systems do it by testing the end year... there are several ways of generating the end year and several ways of coding the test."

>>>>>[Note: they test the end year. This only becomes 2000 in 1999]<<<<<

"I expect failures to occur starting in January 1999, for those systems that use fiscal year = calender year. For those systems that have a fiscal year different from calendar year, the problem occurs the first time the system generates a '00', '1900', or '19100' year internally.

I can imagine a few odd circumstances that would cause systems to fail earlier.

The significance of the Jo Anne Effect is since Jo Anne explained it, we have an understanding of a class of failures that will occur before January 1, 2000. While we've been focused on January 1, 2000, some problems, not predictive, not amortization, not expiration date (as in credit cards.) but some very dull but important production systems fail earlier.

Oddly enough, if we leave these systems alone, they'll probably right themselves after the singularity... the company will have failed, of course." _______________________________________________

Note the use of the term 'not predictive'........in other words, not budetary estimate programs, but production programs used for the day to day operation of the company.

Not 'sky is falling.' But a problem, never-the-less.

-- rocky knolls (rknolls@hotmail.com), August 26, 1998.

Dates to remember, found at various web sites:

Oct 01. 1998 (start of fiscal year 1999 for US Gov't) Jan 01. 1999 (some software failures due to '99' year code) Apr 01. 1999 (start of fiscal year 2000 for New York, Canada and Japan) Jul 01. 1999 (start of fiscal year 2000 for 46 US states) Aug 22. 1999 (GPS 'week' rollover from 1023 to 0) Sep 09. 1999 (some software problems due to '9/9/99' year code) Oct 01. 1999 (start of fiscal year 2000 for US Gov't)

-- John Callon (jcallon@gate.net), August 26, 1998.

Rocky,

<< What you've done is to take a rather trivial case (predictive programs) and announce that 'the sky hasn't fallen.' >>

Not all fiscal year issues that deal with future dates are predictive, and some states may have either had their problems already or will soon. For instance, Texas operates on a biannual budget. Not having lived there in 11 years, I've lost track of where in the cycle that process is, but for arguments sake let's assume that this year begins a biennium and then look at two real, not predictive, data issues that might arise.

1. Contract expiration. State approved vendors are often approved for fixed periods of time. Therefore, when checking to see if a vendor is still on the approved list, you may have a date past 1/1/00.

2. Professional services orders. A single purchase order may cover services that extend the full length of the biennium, and the P.O. expiration date would therefore be past 1/1/00. When the payables system tests for a valid P.O., it is going to have to do the date math to figure out if an invoice is valid.

These are just two simple examples. While at this point predictive calcualtions beyond 1/1/00 are probably much more prevelant than more concrete calcs, don't dismiss the possibility some valid calculations have already been handled by these systems.

Now, having said that, I agree that it is WAY too early to be declaring governmental systems as having demonstrated their compliance.

-- Paul Neuhardt (neuhardt@ultranet.com), August 26, 1998.

Problems could occur if transactions are entered using a day, month and two digit year, then sorted before being processed. Let's assume a fiscal year starting on April 1, 1999. The accounting system probably contains logic that says that any transaction dated earlier than May 1, 1999 is part of April's transactions. After the sort, all transactions dated with the year 00 would seem to have occurred earlier than May 1, 1999, thus might get lumped into April. If they were entries into a budget, the budget figures would be erroneous, and the problem would surface early in the fiscal year - or even prior to the actual fiscal year. If they were transactions of actual income or expenses, the problems probably wouldn't surface until after 1/1/00.

-- Dan Hunt (dhunt@hostscorp.com), August 26, 1998.

In terms of Y2k, look-ahead systems are analogous to the "tip of the iceberg" -- you know, the part of the 'berg visible above the water line.

Yes, many of these systems will have problems on various dates approaching 2K, at which time, with a bit of luck, they will be taken off-line and patched as needed, where possible. Nonetheless, some of these Y2k-approach failures will, in fact, be quite difficult to repair quickly, especially if the particular I/T dept. involved is asleep at the wheel.

However, predictive systems are not the bulk of the problem. Most enterprises have a few programs that look ahead -- some more, some less. But MOST of their software and likely ALL of their Y2k-prone embedded systems are not looking ahead, or are looking ahead in a range of a few hours to a few days.

It is the probability of multiple production real-time or near-real-time systems experiencing simultaneous, inter-connected failures on or about 1/1/00 that is the main concern.

-- Nathan Hale (nospam@all.com), August 26, 1998.

Get a grip people, this focuses on what the whole Y2K problem is about.

Not everything will fail, not everything that fails will be a catastrophy. When things crash incrementally, there will be some incremental solutions.

Great, solve things as they come up. The user (reader) of each prediction will have to be ready to intervene and prevent "stupidty" from promulgating through the Y2K bugs present. But if they don't look for problems... or if they don't solve them... or if they don't expect them...

And when too many million things start failing all at the same time....

By the way, remember that many financial programs are only used quarterly/semi-annually. With bad data coming out from these lesser used programs in the March-April time frame, there will be a second crisis in April 2000, and again in Jan 2001, as bugs are discovred from the first fixes.

-- Robert a. Cook, P.E. (cook.r@csaatl.com), August 31, 1998.