but Ed, does the fiscal year 2048 ring any bells?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I work for one of those state agencies that started their fiscal year July 1... our department produces reports used by accountants/auditors...

all of our inhouse cobol stuff is fixed, installed and successfully running on as/400 ... we changed ALL dates to 8 digit numeric (space is not a factor for us)..

but our State automated management accounting system has used "windowing"... our Departmental Legder is now full of dates like "06/01/48" and "06/01/2048"... we can expect to see "2049" when we produce these reports a year from now...

not a real problem, but confusing and meaningless I'd say... let's hope they identified ALL of the meaningful dates and did better than this overall... must be the 1% still not complete!!!

still waiting for the real facts and getting darn ready for any possiblity I am respectfully yours...

-- booann (cantsay@lovemyjob.edu), July 21, 1999


Sorry, I don't get it.

If "our departmental ledger" is YOUR in-house system, and it has the 2048 date, then you are NOT fixed and successfully running. Wake up.

If that's some other system feeding yours, and if you will produce reports with 2049, then you are not filtering incoming data as you should, and you are NOT fixed and blah blah blah. Still gotta wake up.

If someone else is producing bad reports, but your data and functions and reports are good, then it's not your fault but it may still be your problem. And if you haven't made contingency plans for their error, then you are NOT fixed.

From your other comments, I'd say you're no dummy. Suspect this was just sloppy wording.

Y2k remediation is a whole lot more than signing off on a program patch.

-- bw (home@puget.sound), July 21, 1999.

It sounds like your ledger software may treat '00' as a special value - invalid year or some such thing - and default to 48 (does 1948 have some signficiance?) and the windowers missed that. You should not assume that next year will be 2049.

I don't suppose you can name the state?

-- kermit (colourmegreen@hotmail.com), July 21, 1999.

Humm, as most programmers know, 1 "K" in computer terms is really 1024, so, Y2K really is 2048. No comment... <:)=

-- Sysman (y2kboard@yahoo.com), July 21, 1999.

So the taxpayer's lawyer says "Judge, I submit to the court the question the if this State's accounting department can't get something as simple as a report's date correct, how in the world can we believe that report's data showing my client owes more taxes (or whatever) be considered correc? I move that the charges be dropped and oh, BTW, lets talk about my client's counter-suit to repay all his costs associated with this needless harassment". You're right Booann, not a real problem.

-- Ninh Hoa (tech@univ.now), July 22, 1999.

There will be a few date fields where windowing just simply won't work. Birthdates come to mind. The year a house was built is another. If the period is longer than 50 years, it's impossible to get ALL the date fields to work with ONE windowing technique.

Might need to develope a 2nd routine to handle those dates.

Just a thought.


-- Deano (deano@luvthebeach.com), July 22, 1999.

let me clarify this a little further... sloppy wording is right... ALL dates on our in-house systems written by us on our as/400 were converted successfully to eight digit dates... these are the only systems our dept has control over... however, our accountants need information from our state accounting systems in which reports (not data) are downloaded and printed AS IS... it is the state departmental ledger (our part of it anyway) that has these dates (6/30/2048) on most pages, along with valid 6/30/1999 dates. It looks to me like they "windowed" "non-relavent" dates... I am unfamiliar with windowing and some of the other so called fixes being performed on dates because we converted our data and programs the "right" way... we started back in 1997 and just finished (with the exception of other "more important" (some large) programming projects that were interdispersed. We have two programmers. So... with that said, it is still not a problem, except for the person reading the report and wondering what that date is supposed to mean. It is not something I would want to work with...

ps... thanks for the comments... really

-- booann (cantsay@lovemyjob.edu), July 22, 1999.

oops.. forgot.. the "2049" for next year is the State's response to our inquiry... we can expect it to continue... really...

-- booann (cantsay@lovemyjob.edu), July 22, 1999.

Windowing is just a way of adding the correct century to a two digit date. It requires a 'pivot year' - years before the pivot year are assumed to be in the next century, after the pivot in the next. So if your pivot year is 75, and you see '48' as the year, you interpret that as 2048. Windowing should not affect the two digit date itself. You can only derive 2048 by doing some date calculations or logic, which is not part of windowing.

In other words, you've got a bug that either was in the code to begin with and was not remediated, or was introduced as part of the Y2K work. Just like Ed was talking about. I wouldn't trust any of the numbers coming out of that system without an audit.

-- kermit (colourmegreen@hotmail.com), July 22, 1999.

thanks, kermit, for the input... apparently, this is something they are aware of and are choosing to continue the course.... it is truly unacceptable to me but we are just users in this case and can only bring it to their attention... frustrating, but i'm sure that there will be much of this sort of thing across the board... too many entities have decided to take short cuts, and this is only one "harmless" result... by the way.. i like green too... camo is my favorite!!... really!!

-- booann (cantsay@lovemyjob.edu), July 22, 1999.

Moderation questions? read the FAQ