> tcpdump has no special handling of TZ, it just calls strftime() which handles > TZ as described in strftime(3).
Very little, if anything, of strftime() needs to handle TZ, because it's handed a const struct tm *, generated either by a call to localtime() or gmtime() If generated by a call to localtime(), localtime() has already done all the work of converting a time_t to local time, meaning that it's localtime(), not strftime(), that uses TZ. If, as I suspect, this is a bug inherited from another project's man pages, I'll file a bug there. > Users of tcpdump wouldn’t generally know that strftime() is in use and thus > don’t know to visit that man page. Would users of ls generally know that 1) ls uses localtime() and 2) that, therefore, the setting of TZ affects its behavior? Even if they know 1), they wouldn't know 2) if all they did was look at the localtime() man page, as, at least in Debian 12.5, that man page does *not* mention that its behavior is affected by the TZ environment variable. If they also wouldn't know that TZ affects ls, how is ls different from tcpdump in this regard? Note that ls isn't the only command affected by TZ; date is also affected by TZ, and there are plenty of others. Must all commands that happen either to take local time inputs (and convert them to time_t values by using mktime()) or product local time outputs converted from time_t values by using localtime() mention that the TZ environment variable affects their behavior?
