FW: timezone code - re-entrancy issue

Olson, Arthur David (NIH/NCI) [E] olsona at dc37a.nci.nih.gov
Wed Jan 14 22:37:19 UTC 2009

Given conditional compilation requirements, you'll get to look for
TM_ZONE rather than tm_zone in localtime.c


-----Original Message-----
From: John Dlugosz [mailto:JDlugosz at TradeStation.com] 
Sent: Wednesday, January 14, 2009 5:15
To: kre at munnari.OZ.AU
Cc: tz at lecserver.nci.nih.gov
Subject: RE: FW: timezone code - re-entrancy issue 

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.  


-----Original Message-----
From: kre at munnari.OZ.AU [mailto:kre at munnari.OZ.AU] 
Sent: Wednesday, January 14, 2009 4:00 PM
To: John Dlugosz
Cc: tz at 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 at TradeStation.com>
<450196A1AAAE4B42A00A8B27A59278E70925CC97 at EXCHANGE.trad.tradestation.com

  | So I maintain that it does update the global tzname with the actual
  | 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
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

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
  | 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
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.


More information about the tz mailing list