[tz] strftime %s

[Paul Eggert]

On 2024-01-22 16:00, Paul Gilmartin via tz wrote:

> Is there a format specification for printing such a type or must it first
> be converted to long long by either cast or arithmetic?  I'm uneasy with
> the idea of an integral type that can't be printed.

A similar problem occurs for lots of other POSIX types, such as off_t. 
For off_t one way to work around the problem is to convert to intmax_t 
and format with %jd. For time_t it's a bit more complicated as it might 
or might not be signed, but one can use %jd and intmax_t if time_t is 
signed, %ju and uintmax_t otherwise.


> And what does time_t[] look like?  Might there be slack bits between
> members of the array?

Sure, just like most types. Neither POSIX nor C prohibit padding bits in 
'time_t' and similar types. The only types guaranteed to be free of 
padding bits are signed char, unsigned char, and (if they exist) the 
intN_t and uintN_t types. In the C standard the intN_t and uintN_t types 
are optional; POSIX requires them only for N equal to 8, 16, and 32.

This stuff is relevant only for unusual machines like the Unisys 
ClearPath Dorado (36-bit one's complement but 'unsigned' doesn't always 
work right) and the Unisys Clearpath Libra (40-bit unsigned int and 
41-bit signed-magnitude int). You can still buy these two platforms; the 
hardware, if memory serves, contains Intel Xeons with special microcode. 
Although I hope tzcode would run on these legacy platforms, it's never 
been tested to my knowledge and my guess is that there would be porting 
bugs.

C2x will require two's complement so the C committee has stopped 
worrying about these two dinosaurs.