[HECnet] Re: DECnet event date/time on VAX/VMS

I would point out that sometimes things just 'happen' and it is difficult to anticipate how long something is going to be used or even if that ever occurred to anyone.  So sometimes what got picked was very often 'good' for machines of limited memory and CPU of the time. One example that comes to my mind is the date format used on DECtapes before 1975, which had a representation ((Y-1964)*12.+M-1)*31.+D-1, where "Y" is the year, "M" is the month (1-12), and "D" is the day of the month (1-31).  However, the field itself used to store the date was 12 bits.  Why 12 bits?  One assumes PDP-8, but I really can't recall why. Yet it ran out in 1975 and had to be widened to 15 bits.  Where to find the space?  In short, the 3 bits got scrounged up. Bit 35 of the first 66 words (0 through 65) of the directory block contains the high order three bits of the 15-bit creation date of each file on the DECtape. The high order three bits of the 15-bit creation date for file 1 are contained in bit 35 of words 0, 22, and 44.  Word 44 contains the first (most significant) digit, word 22 contains the second and word 0 contains the third. The bits for file 2 are in 1, 23, 45, etc. If you were to look at this from the design perspective, then it's a bug with a solution that is only somewhat short of horrifying ... At WPI, when we were going through this madness on Tops-10, well, we CS types just sat up and clapped our hands in wonderment.  We thought it, "a fine hack", but what did we know? From my perspective, even in the 1980's if I caught anyone trying to bum a bit or two like that on Tops-20 or anything else I worked on, I put a stop to it.  It's just not worth it when you overflow the field. And dates are hairy.  There's just no two ways about it.   We humans define things for our convenience and don't change until we do change and it makes for a lot of special cases.