At 04:43 PM 12/5/96 +0500, Kishore Kumar.M wrote:
/snip
>HPDATEOFFSET
>============
>
>This intrinsic can be used to add/subtract a specified  offset to/from
>the given date.
>
>SYNTAX
>                       S32       S32     S32     U16A
>        HPDATEOFFSET(inputdate,offset,outputdate,error)

While in the process control industry, we had a routine similar to this but
with additional capabilities.  Our version also included time in a standard
format for both input and output.  There was also another indicator to
identify the type of units that were contained in 'offset'. In this manner,
whenever the incoming time was affected by the factor, the date was also
adjusted appropriately as well.  In this fashion we could add/subtract
hours/minutes/seconds/milliseconds to time and also get the adjustment to
the date if the time adjustment exceeded the boundary for a day (either
negative or positive).

The units we supported were year, month, days, hours, minutes, seconds,
tenths and milliseconds.  (Milliseconds only because it came for 'free'.)
The process manufacturing industry deals with adjusting the time of lab
sample analysis in order to attribute it to the chemical properties of
material at various different stages in the manufacturing process based upon
the time (usually in minutes) it takes for the material to move between
processing stages.  Given that it is a continous manufactoring process, date
and time adjustments have to be manipulated together.

Other application designers in areas such as payables and receivables
generally do not need to adjust time and dates as a pair, and as such, do
not need this type of functionality.  However, there are numerous other
situations whereby time-based adjustments with impacts on dates are used.
You may even want to consider accounting for this in terms of the
re-addressing a 'date-difference' functionality as some industries/etc. bill
for services based upon time (lawyers).  Let's not forget hourly payroll
processing calculations involving ending date/time minus starting date/time
= time worked.  (Shift workers working the late/early shifts have date
factor issues).

Everyone, including myself, has been focused on the issue of handling dates
for Y2K.  I'm just wondering if we've overlooked considering time as an
integral part of providing solutions in this area where it makes sense to
fit it in at this time.  Date and its forms are only one of the units we use
to measure 'time' as a dimension and perhaps we really need to deal with
'time' and its forms, which include the various date formats.  While this
may be a bit beyond the immediate need (Y2K handling), including handing
time in a standard, 24-hour clock format (HH:MM:SS.TT) for some routines
would not be a significant amount of more work I believe, and would prevent
adding additional intrinsics in the future to incorporate it later (if ever)
IMHO.


/jf