[tz] strftime %s

[Paul Eggert]

On 2024-01-14 14:46, Robert Elz wrote:

>    | > 	The struct tm handed to strftime must be one returned by
>    | > 	an immediately preceding call to localtime or gmtime.
>    |
>    | This is good advice,
> 
> It actually isn't.   It isn't required at all.

Although it's not required, it's good advice anyway. Calling strftime 
can be a tricky business (as this thread demonstrates) and following the 
advice means one needn't worry about many of the tricks.

What I've found, when I want to format a timestamp that localtime etc. 
didn't generate, is that I'm typically better off not using strftime. E.g.:

   printf ("Etc/GMT%+d", - (gmtoff / (60 * 60)));

This is better than stuffing gmtoff into a struct tm's tm_gmtoff and 
then using strftime followed by printf - notably because strftime can't 
even generate this particular format.

Most applications are in a similar boat, and stick with timestamps 
generated by localtime etc. when calling strftime. It's exceptional to 
see otherwise, for good reason.


> A C time_t
> might be a count of milliseconds, of microseconds, or 2-seconds, or
> BCD encoded, or almost anything (though I think it is now required
> to be an integer type - I believe it was once allowed to be a float).

Actually in C a time_t can be floating point. It can even be an 
enumerated type, or bool.

POSIX formerly allowed time_t to be floating-point, but that was changed 
in POSIX-2008 as a result of DR 327 
<https://www.austingroupbugs.net/view.php?id=327>. In POSIX-2017, time_t 
can still be bool (!) but in POSIX 202x/D4 the constraints on time_t 
have changed again: now it must be an integer type that is at least 64 
bits wide. (Why 64 bits? Surely 60 bits would have been enough for 
real-world timestamps....)