Why does the C library functions always access time_t values by constant pointers and not by simply copying the value???
I believe this was purely historical. Back in ancient times, the support for 32-bit integral quantities in the PDP-11 C compiler (I *did* say "ancient times"... :-)) was either absent or not quite ready (I vaguely remember that there might have been *some* stuff for "long" in the V6 PDP-11 C compiler, but that it wasn't documented and that it probably wasn't ready to use). As such, times were stored as arrays of two "int"s; the "time()" function took, as an argument, a pointer to the first member of such an array, so that, for example, if you did int now[2]; you could do time(now); and get "now" filled in with the current time. Eventually, "long" became supported, and times became "long"s (or "time_t"s, which were "long"s in PDP-11 UNIX and other UNIXes with 16-bit "int"s), but the APIs weren't fully cleaned up - "time()" was changed to return a "time_t", and to take either a pointer to a "time_t" or a NULL as an argument, with NULL meaning "don't fill this in", but "localtime()" wasn't changed to take a "time_t" as an argument, presumably for binary and/or source compatibility reasons.
I never understood this part of the C lib API. How is portability increased by not using a call-by-value here?
It increased portability to machines with C compilers with 16-bit "int"s and without adequate support for "long". :-)
If there is any good reason that this has been done in libc, then I'd of course also add it to my code. I already did it for consistency with the existing library functions, but I'd like to know why this is supposed to be the right thing to do.
I wouldn't say that, except *maybe* to make the calls look like existing calls, it's the right thing to do. The reasons why it was done in "libc" are compatibility with interfaces defined before 32-bit integral types were available, which may have been a good reason for existing interfaces but isn't necessarily a good reason for new interfaces.