[10] gmtime/localtime performance

[Florian Weimer]

* gmtime and localtime use a global mutex
* TZ variable changes
* File system changes
* Currently: no process restart for tzdata update
* mktime does not use TZ data structures

Both localtime and gmtime currently have poor performance, especially in
multi-threaded programs.  There are two reasons for that: use of a
global lock, and checks for the TZ variable and the file system for time
zone (data) changes.

This project would clean up the current implementation, reducing the
number of global variables, and finally switch over to a lock-free data
structure similar to what we do in _dl_find_object.  We can eliminate
frequent getenv calls with a cache that is invalidated by
setenv/putenv/clearenv (see the other thread).  Finally, the stat call
on the tzdata file could be eliminated with a configuration change
indicator in a permanently mapped /etc/ld.so.conf file.  Such an
indicator could be useful to other caches as well, where we currently
call stat to check for file system changes.

We could contemplate implementing the more extensive NetBSD tzdata API,
but perhaps programmers should use the interfaces provided by libstdc++
instead (although those lack automated reload on tzdata updates).

The lock elimination is perhaps not a big project, but it has been an
open issue for such a long time that it's probably not a small thing,
either.

Another issue in our timezone code is the mktime implementation. It just
makes guesses using localtime (or even gmtime!). This requires it
acquire the lock potentially multiple times. We also have a hard time
ignoring tm_isdst if it does not make sense for the point in time
because we don’t know if the time has coverage in the TZ data. Applying
a correction using a contradicting tm_isdst value trades being wrong all
the time (because the application uses tm_isdst >= 0 incorectly) for
being wrong occasionally (if we ignore a correct tm_isdst, and tzdata is
outdated, we could have produced a correct time).