Browse Prior Art Database

Storing All Dates in Character Format

IP.com Disclosure Number: IPCOM000120996D
Original Publication Date: 1991-Jul-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 2 page(s) / 62K

Publishing Venue

IBM

Related People

Weber, OW: AUTHOR

Abstract

This article describes the ability to maintain any date with the standard OfficeVision* date conventions. Currently, there is no way to store "BC" (Before Christ) dates in character format which can be manipulated with unsigned character arithmetic. This is often required because of the way days are often stored in DIA format. This article describes the invention of a new convention for storing any year in a suitable character format.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 58% of the total text.

Storing All Dates in Character Format

      This article describes the ability to maintain any date
with the standard OfficeVision*  date conventions.  Currently, there
is no way to store "BC" (Before Christ) dates in character format
which can be manipulated with unsigned character arithmetic.  This is
often required because of the way days are often stored in DIA
format.  This article describes the invention of a new convention for
storing any year in a suitable character format.

      To understand the problem, we must first look at the way dates
are often stored in DIA format.  Consider the character string DATE
which stores the date 10/7/1990 as follows: DATE(0) = 7; DATE(1) =
-58; DATE(2) = 10; and DATE(3) = 7; Obviously, DATE(2) contains the
month, and DATE(3) contains the day, but what is not obvious is how
to derive the year 1990 from DATE(0) and DATE(1).  The current
convention provides the following algorithm:
  YEAR = (DATE(0) * 256) + DATE1

      However, one must remember that UNSIGNED CHARACTER arithmetic
is used as follows:
  YEAR = ( 7 * 256) + (UCHAR)-58
  YEAR = 1792 + (UCHAR)-58

      Since the arithmetic is unsigned, the UNSIGNED value of -58,
which is 198, is added to 1792, yielding 1990.  If UNSIGNED values
are not used, the answer would not be 1990. This substantiates the
need for using UNSIGNED arithmetic on this data format.

      The problem occurs when a BC date is used.  Consider the date:
"10/7/1990 BC".  The...