This is a followon to my thread of yesterday, where I raised the question as to whether some countries which got a very late start might in fact not be relying just on fix-on-failure, but instead be a good deal cleverer than we have been giving them credit for.

Diane, here is that definition of encapsulation that I was looking for, from Capers Jones' 1998 book "The Year 2000 Software Problem". It's in one paragraph, which follows in its entirety:

"Encapsulation, interestingly, is the one that Bill Gates, the Chairman of Microsoft, recommended in response to a query from the floor at his CEO summit meeting in Spring 1997. This method simply shifts all dates downward by 28 years so that the year 2000 would be represented by 1972. The rationale for using 28 years is that a 28-year shift will bring the days of the week (Monday, Tuesday, Wednesday, and so on) and the calendar dates (October 6, 7, 8, and so on) into synchronization. Encapsulation has the advantages of being fairly easy to do and does not need much in the way of testing. However, here too there is a performance pealty."

I've given the whole paragraph because I don't want to quote Jones in any way out of context, even though the last sentence about performance penalty in my opinion would best be absent. I've argued with people who think it's a very valid and important point; I disagree.

Now this definition, it should be understood, is a conceptual framework within which implementation approaches can differ. For example, some would turn the computer's system clock back to 1972 and others would just adjust the results of a call to the system date. And you can "age" the data 28 years at various points in the processing sequence. The nitty-gritty processing details of my own favorite approach are given on my Web site www.crosslink.net/~erington but I have to warn you that this is more of a stroll down wirehead lane than most people would be interested in taking.

The reason for my thread yesterday was to raise the possibility that all these Italians, South Americans, et. al. who got such a late start may have had to get their act together in such a hurry that they wound up using their heads better than we've used ours. Or maybe they have flubbed the dub from A to Z and their systems will break apart and wreak havoc. I don't know at this point.

-- Peter Errington (petere@ricochet.net), January 06, 2000

Answers

Peter, this only works if you wrap ALL of the systems or buffer all of the interfaces to do the conversion both ways automatically.

This buffering/wrapping can cost a LOT in performance. (think about every screen, every transmission, every print program, etc)

Chuck

-- Chuck, a night driver (rienzoo@en.com), January 06, 2000.

Peter, You forgot the most important reason you have to go back 28 years to use a date.

Leap Year.

There are many ryears that start Jan. 1 on a Monday, but only once in every 28 years will that calender also include the leap year.

-- Cherri (sams@brigadoon.com), January 06, 2000.

I will let my intelligence show here by asking; if a software program was designed and installed in a new computer in the 1980s and neither were designed to recognize the year 2000, why would it recognize the year 1972 and know it was a leap year?

-- UR2Blame (Upower@jps.com), January 06, 2000.

Because programmers use formulas to determine if a year is a leap year, ie if it is evenly divisible by four. They don't keep a table of years.

-- Amy Leone (leoneamy@aol.com), January 06, 2000.

Actually, Amy, I've seen it done. First you take a really bad programmer ...

In over 25 years, I've seen some incredibly stupid code. A table of years is not the dumbest thing I've seen, but it's close.

-- bw (home@puget.sound), January 06, 2000.

Chuck, the performance penalties you speak of are enough to give me pause wrt on-line systems, but not batch.

Cherri, of course you are right about leap year's contribution to the 28 year cycle. If it were not for leap year we could have a cycle that was a multiple of seven.

-- Peter Errington (petere@ricochet.net), January 06, 2000.

Thanks Peter for the explaination.

Diane

-- Diane J. Squire (sacredspaces@yahoo.com), January 06, 2000.