Have some Unices has their time retval word width fixed anyway, regardless of any 32-bit vs 64-bitness of the o/s? I assume that a 64-bit o/s means that a pointer is 64-bits but in C a uint/int may by default be 32 bits firstly (i) because for many common use cases 64 bits is overkill, (ii) because 32-bits is probably enough - because software was tested with uint set to 32 bits in 32-bit architectures before and worked fine then so 32 bits is enough, and (iii) some compilers prefer to leave uint as 32 bits to reduce the chance if (reasonably rare) risks introduced when porting 32-bit-tested code to 64-bit systems, and (iv) in some 64-bit architectures 64-bit operations have a very very slightly higher cost than 32-bit ones - in x86-64 iirc the slight extra cost is in code size, zero difference in speed, 64-bit operations can have an extra byte in total opcode length compared to 32-bit operations the latter therefore can be regarded as the default.
The time retval typedef should be such that it’s independent of the width of an int or uint, but I suppose the choice for the value of a long or ulong could be a problem - I have no idea. If a time retval type has to be a long that is two machine words on a 32-bit machine then so be it.
(I haven’t done any C in a long while, although I did ten years of it professionally. D has taken over my life. In D, a uint is always 32-bits and a ulong is always 64-bits; and they are guaranteed to be fixed. I don’t like that because there’s no declaration of intent, so I often avoid using those types anyway, preferring uint32_t and uint64_t exact width types and their min width relatives where it matters or where there is any chance that it might matter, to avoid bugs where widths are either ‘just plain wrong’ and have to conform to something else or exact width is part of the algorithm, or where code can fail because of a ‘not wide enough’ error.)
On a 32-bit o/s it 64-bit o/s alike you could make the time retval into uint_least64_t or uint_fast64_t.
I’m just wondering now - there’s no possible reason to make them signed is there? If these times are signed then we could handle dates before 1970. But could that be a bad thing because of ambiguity and compatibility problems with old code and the meaning of the bit pattern that could be 1969 - I’m lost here. My instinct as always is to make such a thing unsigned.