Conference vaxaxp::vmsnotes

694.0. "$BINTIM 0 00:00:00.00 and 10000 day delta-time patch effect." by COMICS::EDWARDSN (Dulce et decorum est pro PDP program) Thu Jun 05 1997 10:43

Just thought I'd point this out, since it may or may not have been seen.
The previous discussion which talked about the concept of $BINTIM returning 
0,0 (it's doing the right thing since what it wants to return is (-0,-0))
is in Volume 10, note 1251.

Once upon a time, if (for whatever reason) you decided to get a delta-time of 
0 00:00:00.00 and used $BINTIM it returned 17-NOV-1858 00:00:00.00 (effectively)
since there is no delta-time representation of this.
When your program continued, assuming that you had a correct delta-time, when 
you subtracted this from the current time, LIB$SUB_TIMES would dutifully signal
an error, since there was the 9999 day limit to delta time and you had just
overflowed it. Quite what the programmer would then do about this I have no 
idea, but one must assume that they handled the status and tried something 
different.

Now, the LIB$SUB_TIMES no longer gives an error, but instead cheerfully 
delivers a delta-time (quite a big one). When the program attempts to turn this
(what it assumes is a valid ABSOLUTE time) into a string using $ASCTIM it of
course is completely unable to comply, or worse still, doesn't modify the 
string which was passed to it so that it contains the previous contents.
This could potentially cause some catastrophies.

Does anyone want to change their mind about $BINTIM being aberrant at the 
singularity of 0?

Ouch.

Any comments?

Neil.