Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-03-30
2001-12-11
Amsbury, Wayne (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06330558
ABSTRACT:
FIELD OF THE INVENTION
The invention is directed to a method and apparatus for recording and reading dates both before and after Dec. 31, 1999, in existing computer-readable storage media (floppy disks, hard disks, RAM, ROM, tape media, or the like) and, more particularly, to such a method and apparatus making it possible to store both legacy data (those written in some existing format) and enterprise data (those written in a new format according to the invention) without ambiguity.
DESCRIPTION OF THE RELATED ART
In many computer applications, dates are represented in six-digit form by a concatenation of the last two digits of the year and digits representing the month and day. For example, in such applications, the date May 10, 1996, is represented in a format such as one of the following: 960510 (YYMMDD), 051096 (MMDDYY), 100596 (DDMMYY) or Julian day plus 96 (YYDDD). Each of the six digits is stored in eight bits in an appropriate storage medium in accordance with a known computer character set. One such character set, used by both IBM-compatible PC's and Macintoshes and known as ASCII (American Standard Code for Information Interchange), maps digits
0
through
9
to bytes 0011 0000 through 0011 1001. Another such character set, used by IBM mainframes and known as EBCDIC, maps digits
0
through
9
to bytes 1111 0000 through 1111 1001. Thus, in ASCII, the date May 10, 1996, is stored as 0011 1001 0011 0110 0011 0000 0011 0101 0011 0001 0011 0000, so that the year 1996 is represented as 0011 1001 0011 0110, while in EBCDIC, the date May 10, 1996 is stored as 1111 1001 1111 0110 1111 0000 1111 0101 1111 0001 1111 0000, so that the year 1996 is represented as 1111 1001 1111 0110. If the date is represented in the format 051096, the first 16 bits will be moved to be the last 16 bits. Eight-bit character sets have traditionally been favored because they can represent every character on a standard keyboard and still have room left over for control codes, line-draw characters, or accented letters.
In another known encoding scheme, each digit is represented by a nibble (four bits), such that each digit from zero through nine is represented as 0000 through 1001. It is conventional, particularly in COBOL, for the last nibble to represent not a digit, but the sign (positive or negative) of the number represented. For example, some databases represent a Julian date in six nibbles (three bytes), thus: YYDDDS. Conventionally, a positive sign is represented by 1100 or 1111 (hexadecimal C or F), while a negative sign is represented by 1011 or 1101 (hexadecimal B or D).
While the encoding schemes described above work for all dates from Jan. 1, 1900, through Dec. 31, 1999, they cannot store subsequent dates without confusion, inasmuch as there is no provision for distinguishing, for example, May 10, 2096, from May 10, 1996.
One known encoding scheme involves using an enterprise format which has more space to indicate the year than the legacy format. One technique is to extend the date fields in databases from six bytes to eight (e.g., from YYMMDD to CCYYMMDD) so that every year from one through 9999 has a unique representation in the enterprise format. However, the implementation of such a solution on an existing computer that does not already use it would require a burdensome process of rewriting much date information already stored. In particular, since all the year data would have to be rewritten at once, crucial systems might have to be taken off-line for long periods of time. In the short term, a data file using the legacy format and a data file using the enterprise format could coexist in the same application through the use of a bridging technique by which years from both files are converted into a common format which the application can use. However, such a bridging technique, besides being cumbersome, does not render the file using the legacy format year-2000 compliant.
Another solution involves determining the century from the last two digits of the year by a range into which the last two digits fall, the source of the year information, or a combination of the two. In one such technique, two-digit numerals above a certain cutoff are assumed to represent years in the twentieth century, while two-digit numerals below the cutoff are assumed to represent years in the twenty-first century. For example, the numerals
28
-
99
can represent the years 1928-1999, while the numerals
00
-
27
can represent the years 2000-2027. Other techniques are more complex. For example, several ranges of two-digit numerals can be established, each being assigned to either the twentieth or the twenty-first century. For example, the two-digit numerals
50
-
59
and
70
-
79
may indicate the years 1950-1959 and 1970-1979, while the two-digit numerals
60
-
69
may indicate the years 2060-69. Moreover, an application can interpret dates according to their source; for example, an application may interpret the two-digit numeral
69
to be 1969 if it comes from a data file of birth dates or 2069 if it comes from a data file of expiration dates. These techniques avoid the difficulty of rewriting all year data, but has its own problems. For example, it is incapable of handling different dates spanning more than a century. Thus, only a limited range of legacy data can coexist with the enterprise data. Second, all systems accessing any given database must agree beforehand on the cutoff, or data will be interpreted erroneously. Third, these techniques offer only a short-term solution, as they merely transform the year-2000 crisis into a later crisis. Fourth, these techniques complicate determination of the day of the week. A variation of this technique involves advancing the cutoff during the lifetime of the database, such that the century of usable dates is successively redefined as 1929-2028, 1930-2029, etc. However, besides its complexity, this technique merely aggravates the problems of having all systems agree on a cutoff and of determining the day of the week.
SUMMARY OF THE INVENTION
The present invention provides a solution to the above-noted problems, that solution being based on the following realization. In legacy formats such as the two-digit ASCII and EBCDIC formats described above, whichever character set is used for mapping digits
0
through
9
, the range of two-byte sequences needed to represent all sets of two digits from
00
through
99
is a small subset of all possible two-byte sequences; this range has as its bounds the two-byte sequences needed to represent
00
and
99
. For example, in ASCII, the range is 0011 0000 0011 0000 through 0011 1001 0011 1001 inclusive. Similarly, in EBCDIC, the range is 1111 0000 1111 0000 through 1111 1001 1111 1001 inclusive. Thus, even if both ASCII and EBCDIC are in use, all two-byte sequences falling outside these ranges are unused and are thus available for a legacy format.
The significance of that realization becomes even more striking when the integer values of the two-byte sequences are expressed in base
10
. A sequence of two eight-bit bytes can represent any value from zero through 2
16
−1=65,535. The integer values of ASCII 00 and ASCII 99 are 12,336 and 14,649, respectively. The integer values of EBCDIC 00 and EBCDIC 99 are 61,680 and 63,993, respectively. That is, the ranges 0-12,335, 14,650-61,679 and 63,994-65,535 are unused in these two legacy formats. Of course, if the bit sequences are taken to represent signed rather than unsigned binary integers, numerical values associated with the ranges change, but the underlying concepts do not. Those skilled in the art will readily appreciate the minor modifications to be made.
The present solution achieves the above-described object by using at least one of these unused ranges to integrate at least two formats (legacy and enterprise) for encoding the year data in the following manner. Existing date data (known as “legacy data” or “old-format data”) are unchanged. For new date data (known as “enterprise data” or “new-format data”), including all data indicating dates after Dec. 3
Amsbury Wayne
Dickens-Soeder, LLC
Stevens Davis Miller & Mosher LLP
LandOfFree
Method and apparatus for recording and reading date data... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for recording and reading date data..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for recording and reading date data... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2573622