FW: timezone code - re-entrancy issue

Robert Elz kre at munnari.OZ.AU
Wed Jan 14 22:00:16 UTC 2009


    Date:        Tue, 13 Jan 2009 14:49:15 -0500
    From:        "John Dlugosz" <JDlugosz at TradeStation.com>
    Message-ID:  <450196A1AAAE4B42A00A8B27A59278E70925CC97 at 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




More information about the tz mailing list