Date Parm Problem

[Stewart, Mark]

CENTURY: TO INCLUDE TO OR NOT TO INCLUDE, THAT IS THE QUESTION? 


With more and more emphasis on resolving Year 2000 problems, the question of
whether or not to switch to a global option of CENTURY INCLUDED comes up
repeatedly. If your application uses or will use multiple centuries - and
the ones that don't are rare - then using CENTURY INCLUDED is the best
approach. It can be very time-consuming to code around the differences
between CENTURY INCLUDED and EXCLUDED. Simply put, if your system option is
CENTURY EXCLUDED, PowerHouse assumes that all dates without a century are in
the DEFAULT CENTURY. The CENTURY option also affects how the various date
functions operate. Better to switch as part of your overall Year 2000
strategy rather than to add a maintenance headache. 

Here we'll describe how the CENTURY INCLUDED|EXCLUDED and DEFAULT CENTURY
options affect PowerHouse date functionality. Understanding this will help
you assess what must be changed as you move your applications to century
awareness and year 2000 compliance. Keep in mind that PowerHouse's basic
date functionality won't change with the new Year 2000 enhancements
scheduled for the 8.1x releases and 7.10.G on OpenVMS. These enhancements
are designed to make it easier for applications to deal with multiple
centuries, but they won't make your applications century aware in
themselves. 

What does century included mean? 

Before we get into the details, we should clarify the way we refer to dates
of different sizes and contents. This is traditionally a confusing issue
because of the variety of date options in PowerHouse. 

We often refer to century-included or century-excluded dates. We also call
them 6-digit or 8-digit dates and we sometimes even refer to 0-century
dates. These terms all refer to how a date is internally represented in
PowerHouse. This internal representation of the date value has very little
to do with the date FORMAT option. Don't confuse an 8-digit date with an
8-digit display format. With FORMAT, we can make any date look like it does
or does not include century digits (or the year, month, or day digits for
that matter). It also has little to do with the storage datatype. We can
store a date in any datatype that can hold the digits of the date, including
various representations such as INTEGER, ZONED, PACKED, PHDATE, and JDATE.
However, the critical issue for this discussion is the actual internal value
of the date item. 

A century-included or 8-digit date indicates a date that includes two
century digits that are non-zero. For example, 19991231 and 20010101 are
both century-included or 8-digit dates. The internal format is YYYYMMDD. A
century-excluded or 6-digit date indicates a date that does not have two
century digits. For example, 991231 and 000101 are both century-excluded or
6-digit dates. The internal format is YYMMDD. 

0-Century Dates and DEFAULT CENTURY 

Sounds simple so far. However, there is a situation where the issue gets
fuzzy. This is the case where the number representing the date has eight
digits, but the century digits are zero. This can be true when an item is
physically large enough to hold eight digits, such as INTEGER SIZE 4 or
ZONED SIZE 8, but there are no significant century digits stored. For
example, the item may contain 00991231. We call these dates 0-century dates.
Record, defined, and temporary items can all contain 0-century dates, of
course, but the problem is usually more acute with expressions. Here are a
couple of examples of 0-century dates: 


> Century-excluded element with larger item
ELEMENT  Birth_Date Date Size 6 ;Store 6 significant digits
...
ITEM Birth_Date Zoned Size 8    ;Store 8 digits
> Assigning a 6 digit value into an 8 digit date field
ELEMENT Birth_Date Date Size 8 ;Logically a century-included date
...
ITEM Birth_Date Zoned Size 8   ;Can store 8 digits

LET Birth_Date = 991231        ;6 digit value assigned
or
LET Birth_Date = REMOVECENTURY(SYSDATE)



The last two are examples of expressions that yield 0-century dates. Numeric
expressions in PowerHouse (even literal values) are always assumed to have
leading zeros. PowerHouse assumes that 0-century dates fall within the
DEFAULT CENTURY regardless of whether the system option is CENTURY INCLUDED
or EXCLUDED. This also means that PowerHouse does not handle dates in
century 0, so its date range is Jan. 1, 100 to Dec. 31, 9999. If PowerHouse
sees a century-excluded or 0-century date in an expression in a date
function, the DEFAULT CENTURY is automatically added before the date
function is evaluated, as in 

DEFINE days-from INTEGER SIZE 2 = DAYS (century_excluded_date) 

However, PowerHouse does not add the DEFAULT CENTURY on simple assignments,
as in 


DEFINE date_with_0_century DATE CENTURY INCLUDED = century_excluded_date



The fact that PowerHouse adds the DEFAULT CENTURY in expressions in date
functions can pose problems if you simply change the DEFAULT CENTURY from 19
to 20 and you're still working with century-excluded dates. Consider the
following: 


DEFINE my_age_in_days NUMERIC*6 = DAYS(SYSDATE) - DAYS(birth_date)



If the system option is CENTURY EXCLUDED and BIRTH_DATE is a
century-excluded date, PowerHouse adds the DEFAULT CENTURY to both SYSDATE
and BIRTH_DATE when it does the DAYS processing. If BIRTH_DATE is 550101 and
the DEFAULT CENTURY is changed from 19 to 20, the calculation on Jan. 1,
2000 gives a result of -20089 (DAYS(20000101) - DAYS(20550101)). This means
you were born in the future and are -45 years old (or is that young?). 

CENTURY INCLUDED and EXCLUDED 

The CENTURY option affects whether PowerHouse deals with multiple centuries
or not. If CENTURY EXCLUDED is specified, then PowerHouse assumes that all
century-excluded dates fall within the DEFAULT CENTURY. In addition, the
results of some of the date functions must fall within the DEFAULT CENTURY. 

The CENTURY option also sets the included or excluded default for temporary
and defined date items that are declared as datatype DATE. And lastly, the
CENTURY option determines whether SYSDATE includes a century or not. This is
important if you have CENTURY EXCLUDED as your system option and assign
SYSDATE to a century-included date. Consider the following: 


TEMP today_is DATE CENTURY INCLUDED INITIAL SYSDATE



If the system option is CENTURY INCLUDED, the value assigned on the first
day of 1998 is 19980101. But if the system option is CENTURY EXCLUDED, the
value assigned is 00980101, a 0-century date. This can be misleading if you
display with a century format such as MMDDYYYY since PowerHouse will use the
DEFAULT CENTURY if the date is century excluded or 0-century. 

The Date Functions 

Let's go through the different date functions and review how they are
affected by the CENTURY INCLUDED|EXCLUDED and DEFAULT CENTURY options. 

ADDCENTURY adds the DEFAULT CENTURY or a specified century to a
century-excluded or 0-century date represented by a date expression. If the
date expression has a non-zero century, ADDCENTURY issues an error.
ADDCENTURY produces a CENTURY INCLUDED date regardless of the system option.


DATE returns a date based on a number of days after Dec. 31, 1899 (on
OpenVMS you can specify a base date). The returned date is century included
or excluded based on the system option. If the system option is CENTURY
EXCLUDED, the returned date must be within the DEFAULT CENTURY. In other
words, the number of days used must represent a date within the DEFAULT
CENTURY, otherwise DATE issues a data conversion error. 

DATEEXTRACT extracts parts of a date. The DEFAULT CENTURY is added if the
century is 0. 

DAYS returns the number of days between a date and Dec. 31, 1899. The
DEFAULT CENTURY is added to the date expression if the century is 0. The
DAYS function is not affected by the CENTURY INCLUDED or EXCLUDED system
option. 

DECIMALTIME is similar to the DAYS function except it returns the number of
days and fraction of a day between two dates. 

LASTDAY returns the date of the last day of the month of a date. The
returned date is century included or excluded based on the system option.
The DEFAULT CENTURY is added to the date expression if the century is 0. For
example, if the date is 000229 and the DEFAULT CENTURY is 19, the resulting
date would be 000228 because the 28th is the last day of February 1900 since
1900 was not a leap year. LASTDAY doesn't care whether the day is valid or
not. It looks only at the century, year, and month. 

REMOVECENTURY removes the century and returns a century-excluded date. It
doesn't matter whether the date has a 0 century or not. The REMOVECENTURY
function is not affected by the CENTURY INCLUDED or EXCLUDED system option. 

To summarize, you can't solve your Year 2000 problem simply by changing the
DEFAULT CENTURY or the CENTURY option. You also need to analyze your code to
ensure that date calculations will still be correct when you do change to
CENTURY INCLUDED. Understanding what the CENTURY option does will help make
your Year 2000 conversion a success. 


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.