Good job, Kishore. I'm happy to share the following thoughts in the hope
that my experience with Adager's date-oriented subsystem will be of benefit
to the HP3000 community.
Criticisms and Suggestions
--------------------------
1. There are several date types used within the HP3000 community which were
NOT listed including, but not limited to:
the 128-bit ALLBASE date
the 48-bit CHRONOS date
MANMAN dates
DataExpress dates (2 flavors)
PowerHouse dates (2 flavors)
32-bit PACKED decimal YYYYDDD dates
32-bit PACKED decimal YYMMDD dates
2. Kishore refers to all of the date types used in MPE/iX as "Standard
Formats".
He should refer to them as "Existing Formats".
3. Only a few of the "Existing Formats" should be designated as "Standard
Formats".
The two characteristics needed by an "Existing Format" to qualify
designation as a "Standard Format" are:
a) ability to span all years from 0000 to 9999 inclusive
b) natural sortability
4. Those "Existing Formats" which are not designated as "Standard Formats"
should be referred to as "Non-standard Formats".
5. I suggest that the following "Type Codes" be designated as "Standard
Formats":
4, 18, 38 and (possibly) the ALLBASE DATE
6. Only "Standard Format" Date Types should be supported by the HPDATEADD and
HPDATEOFFSET intrinsics.
7. I don't see any reason for the types of the 'inputdate' and 'outputdate'
parameters being required to depend respectively on the 'inputcode' and
'outputcode' parameters.
Why can't they simply be treated as arrays containing left-justified input
and output values? In most cases, that is just what they are (i.e., fields
of a record read from a file or a database).
Other Comments
--------------
Adager's Date Examine and Date Conversion facilities are compelled to deal
with invalid (overloaded) dates as they existed within fields of IMAGE
databases.
The term "overloaded" refers to date values which are deliberate invalid
'dates':
Some applications treat NULL (binary zero) 'dates' as 'missing'.
Some treat ASCII zeroes as 'missing' or 'missing but needed'.
Some may use all asterisks or all nines as 'never'.
Others may treat NULLs, ZEROEs and/or repeated characters (or repeated
digits) in other application-specific ways.
Other overloaded dates such as 19960640, 19970650, etc., ... are employed
by some applications.
For some (many?) existing date formats Adager was forced to recognize and
deal with date values treated as 'illegal' by application software.
For example, MANMAN 'dates' (offsets from January 1, 1973) with values
between 1 and 428 are illegal. (429 corresponds to January 1, 1973!)
Kishore's proposal doesn't address any of these numerous and important issues.
Questions
---------
1. If an application is reading dates from a file or database and calls
HPDATECONVERT to map all of the dates to some other Date Types, how will
HPDATECONVERT recognize and treat illegal, overloaded and/or invalid
<inputdate>s?
For example, if the input format is YYYYDDD with value 1973500 and the
output format is YYYYMMDD, what is the output value? (Note that output
formats containing number of days (or seconds, or milliseconds or
microseconds) since a given date must be taken into account in dealing
with such input anomalies.)
Also, How will HPDATECONVERT deal with a YYYYDDD input value of 1955977
when the output format is a bit-packed YYYYDDD such as the HP's CALENDAR
format which provides only 9 bits to hold the DDD (day-of-year) portion?
2. Shouldn't HPDATECONVERT provide some additional parameter(s) to permit
applications the ability to 'tell' HPDATECONVERT which input values are
illegal, overloaded and invalid as well as how the application wants them
to be treated?
Final Comments
--------------
1. I am not fond of HPDATEADD.
a) I don't like the term 'datetoadd' since its values are NOT dates.
Perhaps it should be called 'interval' or 'increment'.
b) I also suspect that, unless and until the algorithm used is described
in detail, unexpected (unwanted) results may occur. Is adding one month
the addition of 28, 29, 30 or 31 days? Is adding one year the addition
of 365 or 366 days?
I hope I'm wrong about such possible ambiguities.
2. Neither HPNLFMTCALENDAR nor HPNLFMTLONGCAL are described. How do they
differ?
3. The proposal should be updated to correctly distinguish between the terms
"Existing Dates", "Standard Dates" and "Non-standard Dates".
In particular, the sentence "Most of the standard date types are naturally
sorted." must be modified.
4. The date formats which are not listed in the current revised proposal
should (must?) be added to the list.
_______________
| |
| |
| r | Fred White [log in to unmask]
| e | http://www.adager.com
| g | Tel 208 726-9100
| a | Fax 208 726-8191
| d | Adager Corporation
| A | Sun Valley, Idaho 83353-3000 U.S.A.
| |
|_______________|
|
