Hi, I forgot to tell the trigger why I initiated this email chain: I was busy with a trial migration to Visual Studio 2015. Visual Studio 2015 has renamed timezone to _timezone (note the leading underscore). As a result, both strftime.c and localtime.c do not compile anymore. So the problem is not theoretical. And the behavior of Microsoft/Visual Studio to add a leading underscore to variables/functions for ANSI variants, is unpleasant, but quite common... If tzcode would use a specialized variable: a. in the header file extern long olson_timezone b. in localtime.c: long timezone definition c. in strftime.c using olson_timezone d. and finaly: #if USG_COMPAT #define olson_timezone timezone #endif In my case, I then can use for Windows: #define olson_timezone _timezone Which solves my issue. Of course, I can decide to not use USG_COMPAT, which prevents me in using a relic from the dark ages :-). Not that dark IMO, since man tzset on Linux still shows the existence of timezone variable. So it is still used (and not all code is re-entrant/thread-safe). Since the migration was a trial (a final migration will probably planned later this year), I 'm not in hurry. Regards, Kees -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, August 31, 2015 17:12 To: Kees Dekker; tz@iana.org Subject: Re: [tz] question regarding 'timezone' variable 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.