HP3000-L Archives

December 1996, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Angie Brown <[log in to unmask]>
Reply To:
Date:
Sun, 15 Dec 1996 10:56:04 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
Stan Sieler wrote:
>
> Keith writes:
>
> >                 The HPDATEADD, HPDATEOFFSET, HPFMTCALENDAR,
> > HPNLFMTCALENDAR and HPNLFMTLONGCAL intrinsics should be
> > functions (not callable subroutines).  These intrinsics simply return a
> > value.
>
> No...it's quite important that they return a value *and* an error code.
> Why?  What happens if the input date is invalid?  Or an overflow occurs?
> Further, if the intrinsics are enhanced to allow multiple date types (as
> they should be), an error code is even more important, to return an error
> like "invalid date", or "attempt to HPDATEADD to an UNKNOWN date value".
>
> BTW, the HP@FMT@CAL@ routines don't return a value, instead they update
> text in a byte array.
> That is, from the Procedure Calling Convetion viewpoint,
> none of the intrinsics with "FMT" in their name "return" a value in
> R28 or R29 ... instead, they are passed the address of a text array.
>


Absolutely, an error code is required.


> >                 The HPDATEADD intrinsic seems error prone.  If 1 month is
>
> I agree...my least favorite!
>
> >                 We need the ability to know the number of days between
> > two dates


Yes!!!


>
> Hence my suggestion for an HPDATEDELTA (or whatever I called it).
>
> Of course, you can always convert two dates into a nice integer type
> (say, days since 0000/01/01), and then subtract them to get the #days
> difference ... but that's precisely the kind of error prone logic that
> every individual user shouldn't have to write!
>


What he said.


> >                 There is no need for the HPDATEVALIDATE intrinsic
> > because passing HPDATECONVERT an invalid date returns an error.
>
> True.
>


Umm, yes, but the HPDATEVALIDATE intrinsic would still be very useful.
I agree that *most* of the time, HPDATECONVERT would do the job, but I
can think of instances when you (well, me) would want to do validation
without conversion.  Please include HPDATEVALIDATE.


> > Also, we plan to use the Null punctuation (separator) character capability
> > you decided to add to the HPDATEFORMAT intrinsic.
>
> Good to hear that other people are also interested in that feature!
>
> --
> Stan Sieler                                          [log in to unmask]
>                                      http://www.allegro.com/sieler.html


Thanks for the opportunity.

-Bob Brown
[log in to unmask]

ATOM RSS1 RSS2