Kees Dekker wrote:
But why not then add an 'extern long timezone' line in either both localtime.c and strftime.c or in a header file of the olson code? That will probably better express that the variable 'timezone' is not of the tzcode library, but is assumed to be a global symbol, somewhere in the system libraries.
That's not the assumption. localtime.c can be used standalone, e.g., even if the system library has no localtime function or associated variables. So we can't declare those variables in the way you suggest. Since this is only a theoretical problem, not a real one, I'm not inclined to worry about it all that much.
If I understand the tzcode well, the timezone variable only affects strftime() when called with '%z' format speficier. So the effect is probably quite limited.
The timezone variable is not used at all on platforms that define TM_GMTOFF. Platforms that do not define TM_GMTOFF are deficient anyway; for example, a call to localtime_r in one thread can mess up the value of 'timezone' in another. Really, anybody building a new platform should treat 'timezone' as a relic from the Dark Ages and not worry about it too much.