FW: timezone code - re-entrancy issue

[John Dlugosz]

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