The localtime.c file does not mention tm_zone, so "this implementation" is missing the proper way. Shouldn't there be conditional code to copy to tmp->tm_zone if that field is present (as indicated in private.h)? I didn't find a strftime implementation in this package, either, so if some "private interface" exists that allows some other package to cooperate with it, that's what I'm asking about. --John -----Original Message----- From: kre@munnari.OZ.AU [mailto:kre@munnari.OZ.AU] Sent: Wednesday, January 14, 2009 4:00 PM To: John Dlugosz Cc: tz@elsie.nci.nih.gov Subject: Re: FW: timezone code - re-entrancy issue Date: Tue, 13 Jan 2009 14:49:15 -0500 From: "John Dlugosz" <JDlugosz@TradeStation.com> Message-ID: <450196A1AAAE4B42A00A8B27A59278E70925CC97@EXCHANGE.trad.tradestation.com
| So I maintain that it does update the global tzname with the actual name | in force at that time, each time it is called. It updates it with the tz abbreviation each time it is called, yes. I personally wouldn't call the abbreviation a "name", so I guess whether I really am disagreeing or not depends upon whether your emphasis there is "the actual name" part or "updates ... each time it is called". The latter is clearly true, and the tzname[] array is most certainly not thread safe - a property it shares with lots of other of the very old unix interfaces. On the other hand, for most applications, which don't go altering the timezone during execution (single common timezone for all threads) and for most timezones, the string assigned is the same every time (for each value of tm_isdst), so the fact that the assignment is being done tends to be hidden. That isn't something to rely upon, but applications that use tzname[] (for some weird reason) will mostly work OK, even if multi-threaded. New applications just shouldn't go near tzname (nor the old timezone and whatever the other global var was that some implementations supported). | If there is no proper way to obtain that, why is it so deprecated that | only ancient programs would use the old way? It's the only choice! No, tm_zone (which I mistakenly called tm_tzname last time) is the "proper" way to get the abbreviation associated with a time_t (after a call to localtime() of course). That one is perfectly safe (just call localtime_r() if you need it). | But that begs the question of where strftime gets the information. No, strftime() localtime() (et. al.) are all internal library functions, they can communicate with each other using private interfaces if necessary. All that matters to the application (or POSIX) is that it works. You're not supposed to know or care how. For this implementation, the tm_zone field is used, an implementation that doesn't have tm_zone in struct tm would use some other way. kre