On 13 Mar, 22:29, "Peter Corser" wrote:
The half minute timing accuracy was down to the programme (sequence)
machines stepping every half minute. The timetables on the machines ran in
half-minute time (from 0300 to 0300 the next day) with 0 at midday - half
minute time was the most you could do within the limits of a computer
integer (8 bit - +/-32767 IIRC).

8 bit would give you +-127, 16 bit is needed for 32767

The Central Line computer control ran internally to quarter minute timings,
but the Timetable software used in developing and printing of the published
timetables (and also the computer control timetables) could only cope with
half minute resolution.

From noon until 3AM needs a signed integer capable of storing upto
1800 values for a half minute resolution, 3600 for quarter minute. 12
bits would do -2048 to +2047, capable of half minute, but not third or
quarter. 12 bits is 3, 4 bit words.

Nowadays of course 64bit time_t is the way to go, although I think
some libraries do 128 bit, which is a little extreme, although some
may say it doesn't go far enough. I think* a 256 bit time_t would be
capable of representing any measurable point in time, and then some.

*
seconds in creation (50 billion years): -- (86400*365.25*50000000000)
Measurable Units of time (plank time) in a second -- 1/(3.3 x 10^-44)
Measurable Units of time in creation (a*b)
~ 4.8 * 10^61
ln(4.8 * 10^61)/ln(2) == 205