Fred writes:
> 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
Does anyone really use CHRONOS?????????
> MANMAN dates
> DataExpress dates (2 flavors)
> PowerHouse dates (2 flavors)
> 32-bit PACKED decimal YYYYDDD dates
> 32-bit PACKED decimal YYMMDD dates
and, probably, 32-bit PACKED decimal MMDDYY dates.
> 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
No...not at all. That's like saying a "Standard Motor Oil" has to be
usable in all engines, at all temperature ranges!
It's important to acknowledge that a number of date data types exist,
and are in fact "standard" ... including CALENDAR and other formats
that don't meet one or both of those two characteristics.
That's why the original proposal had a column showing which standard
formats were sortable, and which were "safe" for Year2000 purposes (if
I recall correctly).
> 4. Those "Existing Formats" which are not designated as "Standard Formats"
> should be referred to as "Non-standard Formats".
(see #3 above...they should all be standards)
> 6. Only "Standard Format" Date Types should be supported by the HPDATEADD and
> HPDATEOFFSET intrinsics.
Only if the entire set of date types are there ... not just those that
are sortable and "0000-9999".
It's *important* for HP provided routines to handle the wide range of
date data types ... we *don't* want users to independantly write code to
do conversion from one "existing format" type to a "standard" ... that opens
the door for problems.
> 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.
It wouldn't be meaningful for a user to pass a pointer to a single
usable character when the data type is documented as 32-bit integer, or X6.
(e.g., a short-mapped pointer to a file of 4096 bytes, with the pointer
pointing to the last byte of the file (last byte of the page)).
Thus, we document what each date type expects.
> 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).
They are treated that way ... as just a bunch of bits....just like the
intrinsics that accept a range of data types, depending on various
factors (e.g., HPFOPEN, FLABELINFO, FFILEINFO).
> Other Comments
> --------------
> 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'.
...
> Other overloaded dates such as 19960640, 19970650, etc., ... are employed
> by some applications.
...
> Kishore's proposal doesn't address any of these numerous and important issues.
Precisely why I'm pushing to have as many date types as possible
have defined values for NEVER/ILLEGAL/UNKNOWN, and whatever else we determine
is needed.
> 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
See above for mention of "illegal"/special dates.
HPDATECONVERT would return an error status, unless it happens that
the standard says that 1973500 is the representation for some special
date for YYYYDDD format (which is unlikely)...in which case the
YYYYMMDD version of that special date is returned (unless there is no
corresponding special date, in which case an error status is returned).
In other words, just what you expect...and what has to be done!
> 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?
Interesting idea...perhaps in addition (and overriding) a standard set
of special values. E.g., an array of directives (19991299 --> NEVER,
19730000 --> UNKNOWN, etc.)
> Final Comments
> --------------
>
> 1. I am not fond of HPDATEADD.
Me either.
--
Stan Sieler [log in to unmask]
http://www.allegro.com/sieler.html
|
