[HECnet] Future problems?

[Johnny Eriksson]

When browsing the Tops-10 sources I stumbled onto this (d36com.mac):

NMXTIM:
IFN FTOPS10,<
        MOVE T1,DATE##          ;GET CURRENT UDT (IN DAYS,,FRACTION)
        MOVE T2,TIME##          ;GET CURRENT TIME (IN JIFFIES SINCE MIDNIGHT)
        LSH T1,-^D17            ;TRUNCATE TO NUMBER OF HALF DAYS.
        SUBI T1,124210_1        ;CONVERT DAYS SINCE 1858 TO DAYS SINCE 1977
        MOVE T3,[^D60*^D60*^D12]
        IMUL T3,TICSEC##        ;SECONDS SINCE HALF-DAY
        TRNE T1,1               ;IS THIS THE SECOND HALF OF A DAY?
        SUB T2,T3               ;YES, RECORD SECONDS SINCE HALF-DAY
        IDIV T2,TICSEC##        ;CONVERT JIFFIES INTO SECONDS.
        IMULI T3,^D1000         ;CONVERT TO NUMBER OF MILLISECONDS*TICSEC
        IDIV T3,TICSEC##        ;CONVERT TO NUMBER OF MILLISECONDS.
        SKIPL T2                ;MAKE SURE WE HAVE A POSITIVE NUMBER OF SECONDS
        TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW
        BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>,,<

Cause:  The 2 byte julian half-day field in an event message is limited
        to 9 november 2021. The routine above has calculated the julian
        half-day, and has found that it overflowed.

        I doubt very much that the date itself has really gone past 2021.
        Probably someone smashed an AC or the routine to get the time
        from the monitor is returning junk.
>)
        RET
>;END IFN FTOPS10

This made me search for some documentation, and I found aa-k181a-tk
which said, amongst other things:

EVENT TIME       Is the source node date and time of event 
                 processing.  Consists of:

                 +----------+--------+-------------+
                 ! JULIAN   ! SECOND ! MILLISECOND !
                 ! HALF DAY !        !             !
                 +----------+--------+-------------+
                 where:

                 JULIAN HALF DAY (2) : B = Number  of   half   days
                                           since  1  Jan  1977  and 
                                           before   9   Nov    2621 
                                           (0-32767).  For example, 
                                           the morning  of  Jan  1,
                                           1977 is 0.

                 SECOND (2) : B          = Second  within   current 
                                           half day (0-43199).

                 MILLISECOND (2) : B     = Millisecond       within
                                           current  second (0-999).
                                           If not  supported,  high
                                           order    bit   is   set,
                                           remainder are clear, and
                                           field   is  not  printed
                                           when    formatted    for
                                           output.

Some observations/questions:

*  The code in Tops-10 actually checks for the half day value beeing
   not more than 16 bits, i.e. it will not trigger until 2066.  This
   means that I will consinder it a typical case of SEP when it does.

*  I have no idea what will happen when the date goes past 9-Nov-2021,
   i.e. when the sixteen bit field gets the sign bit set and possibly
   some software somewhere goes belly up.  Maybe we should try to do a
   controlled test?

*  Will this be/become a problem?  What to do about it?

--Johnny