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.
I would suspect the author had some reason (good or bad) for defining it the way it was.
I think extending it to unsigned 16 bits is a very straight forward and obvious way to fix this.
But to be honest, I think the whole format is completely broken to begin with. Either just specify it as seconds (or days) after some epoch, or have separate fields for each component. Julian half-days? Who on earth came up with that idea?
The formula is just horrific:
JULIAN = (3055*(MONTH+2)/1OO-(MONTH+10)/13*2-91+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1+(YEAR-1977)*365+(YEAR-1977)/4)*2
It probably comes from a desire to do things with 16 bit elements.
It could still have been done so much cleaner.