Description of problem:
While analyzing a performance problem in PostgreSQL, I found out that each call
to strftime() resulted in a stat64("/etc/localtime") kernel call. The source
code says that POSIX.1 requires that strftime act as if it called tzset, which
is fine, but surely POSIX.1 doesn't require stat'ing an external file. Couldn't
this be fixed so that it behaves more like localtime(), ie, we only have to pay
a strcmp() to decide that the info is up to date? Specifically I think strftime
ought to result in the equivalent of tzset_internal(1, 0) not
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Write tight loop involving strftime() call.
2. strace the test program, having made sure TZ envar is not set.
Large number of stat64 syscalls.
Once into the loop, no syscalls should be needed.
It looks like mktime() has the same issue, though I didn't test it explicitly.
If strftime called tzset_internal(1, 0), it would violate POSIX, as it would no
longer act as if it called tzset.
The reason for the stat is to allow for timezone changes.
If you don't want that, you can just use TZ=/etc/localtime or TZ=Europe/Prague
or whatever timezone you want to use.