[log in to unmask] writes -
 
>  MPE/iX Intrinsics using CALENDAR format will behave the same way as today.
>  Intrinsics accepting/returning CALENDAR format (0:7 - Year of the century,
>  7:9 - Day of the year) interpret
>
>      0:7 bits as  "Years since 1900"
>
>   ie, 100 for 2000, 101 for 2001 etc.
>
>>                                         I'm building a new application and
>> want to store dates in CALENDAR format, but I want to make sure it's going
>> to last a while.
>
>  Using CALENDAR store format, you can store upto year 2027.
>
   Most of our (old) Pascal code represents the CALENDAR format (in Pascal)
   as:
 
        CALRECORD = PACKED RECORD
 
              CASE BOOLEAN OF
                TRUE  : (CALINT : SHORTINT);
                FALSE : (
                  CALYEAR: 0..99;
                  CALDAY : 0..366;
                        )
        END;
 
   Please note the CALYEAR range of 0..99.  The Pascal compiler reserves
   7 bits for that info in the shortint; however, should an Intrinsic
   return a CALENDAR-type date with 100<= CALYEAR <= 127, then the run-time
   execution of the program should fail with an out of bounds range-check
   violation.  But not always is this the case - read on.
 
   I happened upon this (the above code) when I was working with CSY (in
   a purely alpha/beta QA capacity) in implementing the ability of MPE to
   produce ANSI-labeled tapes with create and expiration dates in the year
   2000 and beyond.  In particular, the FFILEINFO Intrinsic item 28 returns
   the expiration of an ANSI-labeled tape date in CALENDAR format.
 
   In tests I found the above code *worked* after retrieving the expiration
   date from an ANSI-labeled tape with an expiration date of 2001; that is,
   CALYEAR contained 101.  This should have generated a run-time range-
   check violation, but didn't.  Hmmm...
 
   After some digging, I found all our date routines are in RLs and NMRLs
   and for optimization reasons use the Pascal compiler option $RANGE OFF.
 
   Why?
 
   Benchmarks conducted pointed to quite a bit of overhead due to range
   checking in both CM and NM code (especially for job scheduling!) using
   a variety of date-conversion routines.  Once a routine is determined
   'solid' (read: blessed), range-checking is turned off (with the compiler
   option) and the resultant object code placed in the repective RLs and
   NMRLs.
 
   My point is this:  It is a Good Idea (tm) to hand-check any code that
   deals with dates in CALENDAR format and expects the CALYEAR (of my
   example) to be less than 100.  Problems can include run-time errors of
   the range-check type (note the Pascal defualt compiler option is
   $RANGE ON) and subtle arithmatic problems when range-checking is turned
   off (especially in date-conversion routines :).
 
   Craig "can't wait for February 29th, 2000" Vespe
 
--
Craig Vespe [log in to unmask] Unison Software 811 Barton Springs, Austin Tx.78704
512-478-0611 http://www.unison.com NASDAQ UNSN disclaimer quote ANSI graphics