FYI - More on Six Digit Dates
Monty Solomon
monty at roscom.COM
Fri Aug 26 15:36:03 UTC 1994
Begin forwarded message:
Date: Fri, 26 Aug 1994 09:56:09 -0500 (EST)
Newsgroups: tdr.problems
From: Problem Reporting Service <PROBLEMS at tdr.com>
Organization: Tansin A. Darcos & Company, Silver Spring MD USA
Errors-To: PROBLEM-ERRORS at tdr.com
Subject: 0027 - Responses to Issue #26 (Digest, Long)
To: Recipients of list Problems <PROBLEMS at tdr.com>
Problems Digest Fri, 26 Aug 1994 Volume 94 : Issue 27
Today's Topics:
Reasons for Creating #26
Re: Six Digit Dates (20 Msgs)
Administrivia:
Feel free to circulate this or other PROBLEMS messages. To Reply
to this or any earlier PROBLEMS message, write to <PROBLEMS at TDR.COM>;
for private replies or subscriptions use <problems-request at tdr.com>; or
use newsgroup <tdr.problems>. Please feel free to redistribute this
article widely.
This message is file ftp.digex.net:/pub/access/tdarcos/0027
----------------------------------------------------------------------
Date: Date: Sun, 21 Aug 1994 15:14:01 -0500 (EST)
From: Paul Robinson <PAUL at TDR.COM>
Subject: Reasons for Creating Problems #26
Many of you were already aware of the issue of 6-digit dates. The point
being that whining about "oh dear oh my oh no we're all going to die when
the plants blow up" doesn't solve anything. The main issue - and some
other people also gave out some excellent suggestions - was to think up a
method to {solve} the problem.
We already know the problem exists (or at least I hope most of us do),
but finding a solution to the problem wasn't well publicized.
The best solution in response to my posting comes from
On the secondary note, yes, I am aware that "technically" the century
ends on December 31, 2000. But the problem we have is the "de facto"
end of the century which is the day after 12/31/99 when six digit dates
roll over to 01/01/00. About one advantage we have is that it's a
Saturday. (I looked it up. The real issue is come Monday, 3 Jan 2000
when people are not going to be pleased by what has happened.)
I say "de facto" meaning the date when virtually everyone will celebrate
the end of the 20th Century (December 31, 1999) as opposed to the
logically correct "de jure" end of the Century of December 31, 2000).
There is a good discussion on this issue in James Michener's "Texas",
where some people in the 1890s are discussing when the 19th Century ends.
The Intelligent people point out that time in AD started with year 1,
therefore each century is 100 years and thus the 19th century ends on
December 31, 1900, which is 1900 years later. The book also has an
hilarious religious discussion where a preacher "solves" the issue by
expostulating that God made the first century only 99 years long!
So, the half-dozen or so people who logically arrived at 1901 as the
beginning of the new century, celebrated then.
------------------------------
Date: Fri, 12 Aug 1994 22:42:30 -0600
From: Daniel Packman <pack at acd.ucar.edu>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
> By coding the date into a character field, effectively in base 32, it
> would be possible to encode a larger date and still only use 6 characters.
As a programmer involved exclusively in the scientific area, it is instructive
to see how things are done in "the real world". One rather standard way to
encode date in the scientific world is the Julian Date which as a binary
32 bit number is both more compact and covers a greater range (more than
4000 years into the past and future).
[MODERATOR'S NOTE: Good idea, if the application can support using
binary. I suspect most of the old applications using 6-digit dates are
COBOL programs using either "USAGE IS DISPLAY" (6 characters) or
"USAGE IS COMP-3" (Packed Decimal).
Some of these systems may be running applications that display dates or
that can't do binary conversions, but can handle string conversions.
This is why I felt a "string" format was better than a binary format.
But that's a matter of taste. What counts is what will work.
Switching to a DISPLAY format or a non-binary format might allow a
minimal change to these old programs, some of which may be older than
some of us reading these messages! But if there is an effective means to
allow programs to maniuplate julian dates in binary, that's not a bad idea.]
------------------------------
Date: Sat, 13 Aug 1994 07:27:52 -0400 (EDT)
From: Larry Nathanson <lan at panix.com>
To: Problem Reporting Service <PROBLEMS at tdr.com>
Subject: Re: Six Digit Dates
Just one point-- that it might be wise for companies to start testing
their machines by resetting their system clocks ahead and seeing what
breaks... The risks of causing errors by testing may well be
outweighted by the risks of letting things go till 2000 is months
away...
[MODERATOR'S NOTE: Another good idea. Only problem is you may not be
able to do this in all circumstances. Does a bank change the time on its
ATM network to see what happens? :)
Yes, yes, if someone's running a mission-critical system I would hope
they are running a duplicate system or independent system to allow
testing, e.g. there is a separate set of ATM machines that are connected
to the duplicate system and they dispense memos instead of cash, and can
be used for testing the network and its updates. At least I *hope* they
are doing this...]
------------------------------
Date: Mon, 15 Aug 1994 10:03:23 -0400 (EDT)
From: "John G. Otto" <otto at garnet.acns.fsu.edu>
To: problems at tdr.com
Subject: Re: Six Digit Dates
> ...The problem is probably not as bad as it was, because with the
> introduction of IBM PCs which support dates past the year 2100,
> the issue isn't a problem except to the extent of programs that
> still use six-digit dates...
> What do we need to do?
> (1). If your site has inhouse applications, and lots of source files,
> you need to push for the acquisition of automated checking tools.
> (2). You need to push for the manpower and resources necessary to do the
> work now rather than later, because "later" won't be budgeted for.
> (3). You need to push for the updating of databases to allow full
> 8-digit dates.
> (4). Push for all reports to eliminate use of 6-digit dates, even in
> display fields.
> (5). Find out what your vendor is doing if you use canned applications.
Well, yes, the solution is to stop the problem.
The ISO standard for dealing with dates (8601:1988 superseding 2014, 2015,
2711, 3307 & 4031) has been around for a while; Control Data was beginning
to make use of it some 15 years ago.
Interestingly enough, Gary Houston, the author of the summary available
on-line, does not follow the standard himself within that summary, using
little-endian form (as is customary in Europe, and as opposed to month
first inside-out form customary in the USA).
An example of ISO 8601:1988 compliant date/time is:
2001-01-15T14:23:38 or
20010115T142338
One nice feature of the form is that it sorts as one field without converson.
[idea regarding using alpha to cram more into same size date field deleted]
> If we work on the problem now while there is time, we can do this with
> less error and better control, than trying to rush fixes in November of
> 1999 when errors could spell disaster.
Think of it as employment security. :B-)}
jgo
[MODERATOR'S NOTE: I believe the 6-digit date form is a FIPS Standard and
is required in certain government computing applications. Anyone know if
this was true and if this was ever repealed?]
------------------------------
Date: Mon, 15 Aug 1994 10:07:08 +0700
From: Tyrannosaurus Wes <wes at windjammer.raxco.com>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
>>>>> "0026" == Problem Reporting Service <PROBLEMS at tdr.com> writes:
0026> The problem is the issue of six-digit dates and the turn of
0026> the century, now less than six years away.
0026> And I thought of a method.
0026> In fact, if one wants to encode the month and day - Month
0026> encoded to add A,B and C and day encoded as 1-9 and A-V, it
0026> is possible to use 4 digits for the year and still fit
0026> everything into 6 bytes. Or encode both and fit everything
0026> into 4 bytes.
0026> This would also then work for places using packed decimal
0026> for the six-digit year and thus only allowing 4 bytes.
Most modern languages, operating systems, and database management
systems have some sort of intrinsic date format. Whenever software
systems are modified to support extended date handling, a better
approach, I feel, would be to convert the 6-character date fields
already in use to the "native" date format. Modern languages and DBMS
provide support for manipulating dates in these formats, alleviating
problems with oddities like leap-seconds, leap-centuries (of which
2000 is one), and the like.
Data-file conversion is an issue with this method, but is an issue
with any method; the dates *must* be converted. Since this method may
require expanding the date field, the availability of direct-access
storage may become an issue.
--
Wes Peters -- software engineer, network coordinator, system wrangler, chief
cook and bottle washer, Raxco Inc., Orem UT Wes at Raxco.COM
[MODERATOR'S NOTE: That was exactly what I was worried about. I had to
think of some method that would use the same amount of space or less, yet
still cover a full date field. Also, there is still some software that
only generates 6-digit dates. I think DBASE III's DATE() function
returns a date in the form MM/DD/YY. Not good.]
------------------------------
Date: Tue, 16 Aug 1994 15:11:46 -0500
From: Tim Horrigan <u2re9toh at hanover-crrel.army.mil>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
It's a sad commentary on human nature that this problem wasn't anticipated
35 years ago when this software was first being written.
This problem is coming up and biting organizations much earlier than one
might think. For example, Dartmouth College (like many colleges,
presumably) belatedly discovered last winter that it was possible to have
members of the Class of '00 being registered as soon as that coming summer
(i.e, what is now right now.) (This happens, for example, if some kid opts
for a 5-year program such as a 3-2 Engineering program and then decides to
take a year off before starting her course of study.) They _think_ they
found all the date fields in their software, but of course they can't be
sure.
Disclaimer:
The views expressed in this message are certainly not those of
the Army Corps of Engineers, and they might not even be mine if
I were to take the time to think things through a little more
thoroughly :-)
------------------------------
Date: Tue, 16 Aug 1994 14:11:36 -0500
From: "Patricia J. Seymour" <pseymour at iseg01.imd.cig.mot.com>
To: problems at tdr.com
Subject: Re: Six Digit Dates
Hello-
I've just read the article "Danger of Six-Digit Dates" in the latest
Risks Digest. I understand and agree about the magnitude of the
problem, but I don't understand why you are considering Friday,
December 31, 1999 to be the "last date of this century." Centuries
have one hundred years in them, not 99. The true eve of the next
century is December 31, 2000. (That's why the film was entitled
"2,001") It's the same as trying to buy something that costs $2,000
with only $1,999 in your pocket. (We are assuming tax as already being
figured in the price. :) )
-Patricia (Illinois)
[Moderator's Note: Yeah, yeah, I know and I got burned on this one; I am
aware of the issue, and intend to use it as an excuse to celebrate twice!
Seriously though, does anyone think we're going to convince the vast
majority of people, or TV programs doing reviews of the 20th Century that
it ends on December 31, 2000? Assuming Dick Clark is still around
(doesn't that man ever get any older??) want to bet his show on
December 31, 1999 is going to claim we are beginning the 21st Century! ]
------------------------------
Date: 16 Aug 94 16:05:01 EDT
From: A S Oliphant <100126.2551 at compuserve.com>
To: Problem Reporting Service <PROBLEMS at tdr.com>
Subject: Re: Six Digit Dates
Interested to read your mail. I have been suggesting such scenarios to several
employers over the last 15 years. In fact my current one is starting to grapple
with the issue at the moment.
However, by a quirk of fortune, our problem is possibly not as big as you
suggest.
Without naming names, I work in the life assurance business. We computerised
early on and dates presented us with similar, if opposite, problem then. That
was the need to record dates of birth for existing policy holders born in the
19th century. We therefore devised a method using 4 bytes as follows:
Byte 1 - day of month
Byte 2 - month
Byte 3 and Byte 4 - year (+sign) e.g. 194C is 1994, the C is the sign to make
the whole field look like packed decimal (ebcdic).
While we have to write special routines to decode and manipulate these dates, it
means that our end of century conversion will not be as onerous as for some.
[Moderator's Note: I'm glad to hear that. This one isn't too bad a
suggestion. There are several good ideas being given out here, and I hope
some of them will help people fix their systems before they collapse.]
------------------------------
Date: Tue, 16 Aug 94 14:27:36 PDT
From: Andrew Klossner <andrew at frip.wv.tek.com>
To: PROBLEMS at tdr.com
Newsgroups: comp.risks
Subject: Re: Six Digit Dates
Just in case nobody else pointed this out ...
"The last date of this century is Friday, December 31, 1999."
The last date of this century is 1 January 2000. Centuries run from
x01 through x00, because there was no year zero.
[Moderator's Note: Yeah, yeah and it's illegal to drive 70 MPH on a public
highway in the U.S., but people still do it. I made the mistake of
admitting that I, on the occasional time I rent a car because I have to go
somewhere, *do* usually drive 55 in the fast lane of the freeway, and
people considered *me* a criminal. It's not popular to be 'de jure'
correct when that is entirely different from what the general public sees
as the 'de facto' correct answer.]
------------------------------
Date: Wed, 17 Aug 94 11:02:52 +0200
From: Udo Voges <voges at iai.kfk.de>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
If a solution to this problem is found, it should include
the correct international representation of the date,
eg. year/month/day, which solves also the misunderstandings
with month/day/year and day/month/year.
[Moderator's Note: Good point. More than half of the addresses on this
list are identifiable as being outside of the U.S., Canada or Mexico, not
counting the .COM or .EDU sites that might also be.
There are probably three major formats for dates, e.g. M/D/Y as the U.S.
does it, D/M/Y is common in Europe or Japan, and Y/M/D as is also used
in Japan, I think.
Possibly I should write an Internet Draft for publication as an RFC to
publicly define a standardized date format for computer data files and
to help fix the six-digit issue. Any suggestions?]
------------------------------
Date: Wed, 17 Aug 94 11:38 BST
From: mathew <mathew at mantis.co.uk>
To: problems at tdr.com
Newsgroups: comp.risks
Subject: Re: Six Digit Dates
Mike Sullivan <74160.1134 at compuserve.com> quotes:
>>From: Problem Reporting Service <PROBLEMS at TDR.COM>
>>Subject: 0026 - Exactly. What do we do? (Six Digit Dates)
>>Date: Fri, 11 Aug 1994 23:00:58 -0500 (EST)
[...]
>The last date of this century is Friday, December 31, 1999. 12-31-99.
>Want to tell me what the next date after that is? Saturday, January 1, 2000.
>01-01-00.
Incorrect.
The last date of this century is Sunday, December 31st, 2000.
The first date of the 21st century is Monday, January 1st, 2001.
Hmm, I won't be asking TDR to fix *my* date routines...
( Arthur C Clarke chose "2001" as the title of the book and
film because it's the first year of the next century. )
[Moderator's Note: Clarke also said that the worldwide phone system would
eliminate tolls on all calls anywhere in the world. I'm not sure how
that would be paid for, but it's an interesting concept.
Oh yes, is he referring to ME when he uses the term 'TDR' or
the services of my company? :) Actually, that's why my domain name
is 'TDR.COM' because I have used a login name of 'TDARCOS' for many years,
and people started referring to me as TDR. The name stuck, so I decided
to use it.]
------------------------------
Date: Wed, 17 Aug 1994 11:35:31 -0400 (EDT)
From: Bradley White <bww+ at transarc.com>
To: Problem Reporting Service <PROBLEMS at tdr.com>
Subject: Re: Six Digit Dates
> Which date is earlier, 01/01/99 or 01/03/00?
I would say 01/01/99.
> What is the mathematical difference between 12/15/99 and
> 01/03/00? About 99 years.
I would say 19 days.
If you are only going to use `00'-`99' to represent a year, you need to
select an appropriate point of discontinuity. The choice is undoubtedly
time and application dependent. 99->00 clearly isn't the best choice at
the moment for almost all applications.
[Moderator's Note: No it isn't, but I suspect many applications didn't
take the effective year in mind when they were coded, but take the actual
year.
But from a mathematical standpoint chances are - unless the program was
designed correctly in the first place - I'd figure a program would treat a
date of 12/31/00 as earlier than 01/01/99. By 98 years and change.]
------------------------------
Date: Wed, 17 Aug 1994 14:59:00 -0400
From: Dan Astoorian <djast at utopia.druid.com>
To: risks at csl.sri.com, PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
>>From: Problem Reporting Service <PROBLEMS at TDR.COM>
>>Newsgroups: tdr.problems
>>Subject: 0026 - Exactly. What do we do? (Six Digit Dates)
>
>By coding the date into a character field, effectively in base 32, it
>would be possible to encode a larger date and still only use 6 characters.
>By encoding the year to use the letters of the alphabet, e.g. AA through
>ZZ plus A0 through Z0, it is possible to cover more than 900 years, e.g.
>start counting with 1400 through 2300, thus covering any date that could
>have occurred during civilization.
Rather pessimistic to assume that civilization will end before the year
2300, wouldn't you say? ;-)
I'm sure it comes as a surprise to no one that this approach has been
considered before. There are a number of problems with it.
Given that with current dates, the year <x>9 is followed by <y>0, (for
0 <= x < 9 and y := x + 1), imposing an ordering which used the entire
space of [0-9A-Z][0-9A-Z] would necessarily be a fairly complicated
algorithm; in fact, I expect that any such ordering (allowing A-Z for
the units digit of the year) would be unwieldy for a human
troubleshooter to determine the real year from the encoding easily, and
equally difficult for an implementor to get verifiably correct. Using
alphabetic characters for the tens' digit would still buy a couple
hundred years, though.
However, any such "extension" to the storage encoding needs to be
mapped to a readable date for the end users: Reports generated with
dates of "Monday, January 3, 19A0" will not be acceptable (even if the
report does not cause errors by being used as input to other software
modules.) This is at least as large a problem as the storage issue.
>One of the things that is necessary is to make programs expecting numbers
>fail so that they can be changed. Programs that read these records will
>have to expect both old and new format records, while programs that write
>them should only output the new format.
This assumes, of course, that the failure mode of a program which got a
non-number when it expected a number will be reasonable; how valid is
that assumption? I can easily imagine programs figuring the difference
between the years 2000 and 1998 by the calculation
"98" -> (('9'-'0') * 10) + 8 = (9 * 10) + 8 = 98
"A0" -> (('A'-'0') * 10) + 0 = (-47 * 10) + 0 = -470
"A0" - "98" = -470 - 98 = -568 years.
(Of course, if the computation were performed in ASCII rather than
EBCDIC the difference would only be +72 years.)
We haven't even spoken of the issue of how dates will be communicated
*between* machines which use 6-digit dates.
>If you have better ideas on how to solve the six-digit problem, please
>write back.
Probably the most common suggested solution is to change the
date-comparison algorithms to consider any date with a numerical value
smaller than some threshold <N> to be a 21st-century date; eg., say that
'50' means 2050, but '51' means 1951. This works if all the dates you
want to represent are within a century of each other (and, of course, if
the years wrap around from 99 to 00 smoothly, which isn't a given; what
happens if you subtract 2 years from (20)01? Will you get "99", "-1",
or something worse?)
The other common suggestion is to add a separate 2-digit field for the
century; as packed decimal this would require only one additional byte
for each date represented in the record. There's no law that says that
the century and the year need to be physically contiguous, so it may not
be that difficult to find a couple of unused bytes somewhere in the data
records to keep the extra information without requiring drastic database
changes. This would also mean that many reporting programs would not
need to be changed immediately, as they would continue to produce
reports in the same form as before, assuming that they were not
hard-coded to prepend "19" to the year.
For many companies it is cost-effective to solve the *general* problem
(the mainframe) rather than the specific problem (6-digit dates); the
mainframes are expensive to maintain, and they won't be around forever.
Cobol 85 compilers and online transaction processing systems are
available for Unix. (At the RISK of Cantering: my employer sells a Unix
OLTP system for COBOL users; for more information send mail to this
address or to info at allross.com. 'Nuff said.)
[Moderator's Note: How about 'mea culpa', 'mea maxima culpa' for a plea
for mercy for me and my big mouth in not thinking about the way that came
out. Or should I say, 'for me and my fat fingers?' :)
'2399' was a reasonable alternative to 9999; my use of the term
'civilization' was pushing backward toward the earliest possible date that
someone would have date references for. Since Columbus landed on Cuba in
1492 I doubt we need to worry about earlier dates. (Yes, I know about the
Vikings being in North America in the 1100s, but they didn't publicize it
very well.)
Adding space to some data files is not an option in the near future in
some installations. I think TRW, for example, has something like 180
million credit reports on file. If each report has 10 entries that use
dates, that's 3 billion bytes of disk space that have to be added just to
stretch these files by a measly 2 bytes. Then, you have to go back and
edit every single program that uses those files to tell them that the
file is now two bytes longer in every record. Many of these files are on
old DASD which means the files would require migration to expand them and
thus would raise all sorts of problems.
Personally I think that if programs have to be changed to fix this
problem - and they do - the change should be as light as possible and the
minimum necessary to fix it, considering how fragile many programs are.
Changing a program to add a means to recalculate the date is probably
less of a change than expanding every record definition and reference to
the file data to add two bytes.
In the long run this is the correct answer, e.g. that the file data should
support 8 digit dates, and hopefully as systems move off those old
mainframe dinosaurs that served us so well, the data files will be
updated.
Some might say 1700 might have been far enough back. Consider that here
in Maryland a local jurisdiction will celebrate a special anniversary in
three years. As it says on the freeway signs:
Welcome to Prince Georges' County, Established 1697.
As far as 2399 is concerned, I personally, do not expect this civilization
to last even that long. I will be surprized if the current civilization
lasts another 50 years; whether things get better or worse is a matter of
taste; explaining my reasons why is too complicated an issue to do in less
than a complete issue and is way off the subject here. However, the point
has been raised so I will discuss it in a later issue. ]
------------------------------
Date: Wed, 17 Aug 94 14:33:55 -0500
From: Steve Peltz <peltz at cerl.uiuc.edu>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
Re: Article forwarded to RISKS
Instead of doing funny things with the year field, it seems
much easier (and easier to deal with BCD fields) to play
with the month. Add 12 to the month for the next century.
Add 12 more for the century after. That should hold us for
about 7 more centuries into the future. If that isn't
enough (and if a program sticks around through 20 years of
computer evolution, it will probably last 800), add 33 to
the day field and go through 8 more centuries. At that
point, it is probably time to put your foot down and demand
that the old programs be completely re-written (but at
least you still have another 8 centuries to go before they
have to be completed, since you can still add another 33 to
the day field).
[Moderator's note: 'If a program sticks around through 20 years of
computer evolution, it will probably last 800.' That statement probably
needs to be recorded for posterity. This solution sounds like an even
better solution than mine. So far, this sounds like the best 'interim'
solution to the problem. 'Interim' meaning until what the previous two
messages stated; make the data files two bytes bigger for every date
field. Preferably making the addition contiguous to and part of the
date.]
------------------------------
Date: Thu, 18 Aug 1994 12:32:37 -0500 (EDT)
From: Jeff Jonas <jeffj at telerate.com>
To: problems-request at tdr.com
Subject: Re: Six Digit Dates
I just read your posting in the RISKS digest about the 6 digit year problem.
Unfortunately, most COBOL programmers may have used packed-decimal coding
or BCD for the year, where there's really no tolerance for
digits other than 0-9 despite 4 bits per digit.
Even if you could force values >9 to the date, the arithmetic routines
normalize the year back to values 0-9.
I'm fortunate to work in the Unix environment where the native date
format is in seconds since Jan 1, 1970 so that reaches well into 2000
before wrapping.
[Moderator's Note: And VMS (the operating system for VAX and Alpha
processors) goes back to the 1800s as does the $HOROLOG function of the
MUMPS / M Programming Language.]
------------------------------
Date: Thu, 18 Aug 94 10:46:42 edt
From: Mike_Perry at dge.ceo.dg.com
To: problems-request at tdr.com
Subject: Re: Six Digit Dates
Message:
I saw your posting via RISKS DIGEST.
I hope your worst fears aren't realised, but things ARE going to go
bad, that's for sure, and I'd be surprised if they aren't already,
with calculations that look forward in time - as you say, it's less
than 6 years away. I encountered this (type of) problem several years
ago with a project planning system that used absolute week numbers
based on week1=date_the_system_went_live. 3 digits were allowed for
week numbers, and sure enough, some 14 years later, a project with a
5-6 year timespan tripped over to week 0.........
BTW - the last day of this century, (and this millenium) is December
31, 2000, not 1999.
Regds., Mike
------------------------------
Date: Thu, 18 Aug 1994 12:17:25 -0700
From: Brian Kantor <brian at nothing.ucsd.edu>
To: problems-request at tdr.com
Subject: Re: Six Digit Dates
no doubt a million other people have written to point out that the last
day of the century is Dec 31, 2000, not 1999. The rest of your note is
well-taken, though.
- Brian
------------------------------
Date: Fri, 19 Aug 94 16:46 CDT
From: "William G. Lederer" <wgl at mcs.com>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
Just one note on your otherwise fine and informative article. The century
actually does not end until the end of the day on December 31, 2000.
I predict, however, that journalists and the like will also get this
one wrong.
[Moderator's Note: I fully support your prediction. :) ]
------------------------------
Date: Mon, 22 Aug 1994 11:54:25 -0600
From: Thomas McNeill <TGM at wordperfect.com>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
In almost all cases it will not be necessary to change to 8
digit dates, at least not immediately. All you have to do is
change the routines that calculate the difference between
two dates. In those routines, add 2000 to years less than 50
to arrive at the full year, and add 1900 to years greater than
or equal to 50. This will gives us approximately 50 years of
breathing room to implement the real fix, which is to go to 8
digit dates.
Changing the encoding scheme in the disk files so that 6
bytes encodes a larger range of dates would require not
only recoding the applications, but also making passes
through all the files to change the encoding scheme.
[Moderator's Note: This is a good answer to the message sent to me
privately on the subject, which appears as a summary as the last item
in this digest, two entries below. ]
------------------------------
Date: Wed, 24 Aug 94 15:59:09 PDT
From: Russell Brand <brand at reasoning.com>
To: PROBLEMS at tdr.com
Subject: Re: Six Digit Dates
I am one of the developers of a program understanding & re-engineering tool
called Refine/COBOL [tm]. Some of the most interesting applications of our
tool have been to modify legacy COBOL systems so as allow them to be continue
to be used past the year 2000.
Some of my users started hitting the problem in 1993 because as their
budgetting offices had 7 year projects. For some of these firms, they are
using the program analysis tools to automatically find things that look like
dates, and modify comparisions and differences such that 00-49 represents
2000-2049 rather than 1900-1949.
While there was some discussion of using other encoding (trating the high order
digit as HEX rather than decimal) and making somewhat different set of
conversions. I would be interesting in hear other approaches that have been
attempted.
Some description of my groups work can be found in the May 1994 issue of
_Communications of the ACM_ or on our world wide web server
www.reasoning.com
/Russell
brand at reasoning.com
------------------------------
Date: Fri, 26 Aug 1994 08:21:55 -0400 (EDT)
From: Paul Robinson <PAUL at TDR.COM>
Subject: Re: Six Digit Dates
From: Paul Robinson <PAUL at TDR.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
On Thu, 25 Aug 1994, "someone" wrote to say the following, which has
been paraphrased:
Arthur C Clarke's book "The Ghost of the Grand Banks" discusses
this, and in the book a character writes a benign computer virus
whose task is to change routines using 2 digit years to 4 digit ones.
Interesting concept.
One of the problems is huge databases; some of them are currently, shall
we say "maxxed out" on multipack systems in terms of the amount of space
used; to add any material to the files would require either shutting down
the system and rebuilding the database, or running a specialized
conversion program simultaneously with the applications so that the
conversion program is doing a rebuild to add the additional space to the
file as a new file, while the applications in use are running, plus
logging their transactions so that their updates can be carried across.
Either is not a pleasant idea.
Beyond that, let's say a company has, say, 125 million current transaction
records covering such things as last 90 days of payments, charges, etc,
e.g. a bank with, say, 2 million credit cards, loans and depositors, an
average of perhaps 50-60 transaction lines per customer. To add a measly
two bytes to just update current transaction information means adding a
whopping 250 million bytes of storage just for this. If they have even
longer data retention periods (let's say it's more than 90 days) the disk
drive requirements are somewhat more.
Mainframes aren't PCs. You can't just simply add another disk drive which
costs about $500 for 1gb. First, mainframe drives are more expensive for
a variety of reasons including multiple access. Next, you have to add the
disk space (which may require updating operating system tables), then
migrate the file records over to the new pack, while deleting the old ones
in order to free up space, unless you want replicated copies of the
database at the same time, which could get expensive. Assuming those 125
million current transaction records use about 100 bytes each, this means
the bank has 12.5 thousand million (12.5 billion) bytes of current
transaction data. That would be a lot of extra disk space and even
converting is going to be a lot of I/O and will take time.
I am not convinced of the benefits suggested by your cure. To make
those modifications will require amending many thousands of lines
of code.
Exactly. And we will have to have automated tools; the job is too large
to do manually. I'm thinking of creating some. (I could use the money,
too. :) ).
So why not simply expand to 4 digit dates at the same time,
which would be stable for 8,000 more years until we have to
change the date system anyway...
Eventually that will have to be done. But one of the things to remember
is that because many computer systems are extremely fragile, that we want
any change to be (1) as simple as possible and (2) do only the minimum
necessary to avoid damaging the system as running.
They used to tell something similar to this to physicians (in relating to
an attempt by programmers not to make a change that damages the running
application), "First, do no harm." Also, we should try to make the
changes so that if we can, we prevent the occurrence of "feature
interactions".
A "feature interaction" is when doing one thing causes a change or an
indeterminant state in another, e.g. if you have both call waiting
(allowing you to take two calls on your line) and hunt group (causing
calls coming into your line to transfer to another line) both on the same
line, when the second call comes in, does call waiting kick in first
(allowing the second call on the line) or does hunt group kick in first
(transferring the second call)? It depends on how the software is set
up, which means that using both call waiting and hunt group on the same
line causes a "feature interaction."
[Moderator's Note: I think it's clear, long term we will have to code
8-digit dates into files, and if we use something akin to the suggestion
to change the day of the month or the day of the year, we can stave off
major code changes until these applications migrate to servers and such
and it solves the problem for us, as long as the new files have the space
in them. Which of these is the acceptable solution is a matter of taste;
I like the changing of the day or month fields so that programs that
don't change them will show up with bad dates in display fields.
Question to consider: how much "free" space should be left in a data file
and when should it be rebuilt? Here's a suggestion; any database should
initially provide 20% of the space in each record for future use, e.g. in
a record that needs 100 bytes, the record should be 120 bytes (or make it
128 to be even with a power of 2 since it's close) and then the files
should be re-epanded when the amount of free space drops below 10%, so
that you don't have this kind of crunch again.
This may seem ridiculously high and wasteful, but how wasteful is it to
have to stretch and squeeze to add something that has to be done that had
the resources been left there ahead of time, would not be a problem?
Harvey Mackay, in his book "Swim With the Sharks" says that you should
"dig your well before you are thirsty.". I think the comment is
appropriate here. Provide the space in advance, before it's needed and
finding the space later is less of a problem. Fixing the 6-digit problem
would have been trivial if this had been done.
Yes, yes, I know disk space was very expensive a while back; I remember
about 12 years ago when one of my bosses was trying to Jew down the
supplier of a disk pack to reduce the price of a 100 meg pack from $700 to
$600. This is for the removable pack alone, the disk drive was something
like $12,000. In any case, the price of disk space should no longer be as
much of a problem. (Then again, some places would have no trouble paying a
consultant $5,000 to tell them the information I supplied in issue #26 and
this issue, but would take forever to raise $2,000 if one of their
employees wanted to order a couple GB more disk space.)
Am I wrong, or are there a lot of systems that don't have the space
to add two bytes to each record in a major, company-critical data base
because the record *is* "maxxed out" and there is no room left in the
records for additions without rebuilding the database, which is seen to
be about as much fun as anesthesia-less root-canal surgery? You can
write me privately if you don't want to wash your dirty laundry in
public.]
------------------------------
End of Problems Digest V94 Issue #27
************************************
More information about the tz
mailing list