FW: timezone code - re-entrancy issue

John Dlugosz JDlugosz at TradeStation.com
Tue Jan 13 19:49:15 UTC 2009


	-----Original Message-----
	From: kre at munnari.OZ.AU [mailto:kre at munnari.OZ.AU] 
	Sent: Monday, January 12, 2009 9:28 PM
	To: John Dlugosz
	Cc: tz at elsie.nci.nih.gov
	Subject: Re: FW: timezone code - re-entrancy issue 
	    Date:        Mon, 12 Jan 2009 17:45:39 -0500
	    From:        "John Dlugosz" <JDlugosz at TradeStation.com>
	    Message-ID:
<450196A1AAAE4B42A00A8B27A59278E70925C93A at EXCHANGE.trad.tradestation.com
>
	  | So what is the way, in this code (or POSIX), to get the name
of the 
	  | timezone?
	For what you ask there, there is none, here, or elsewhere.
tzname[]
	(despite its name) is not that, it is the current timezone
abbreviation (which 
	in this code is better obtained from tm_tzname if it is really
needed for 
	anything - I'd actually suggest avoiding its use if you possibly
can, use the 
	numeric offset instead).


Hmm, the code reads

 tzname[tmp->tm_isdst] = &sp.chars[ttisp->tt_abbrind];

where ttisp points the record actually found that is in governance at
the specified time, and whose offset is used in the final calculation.

So I maintain that it does update the global tzname with the actual name
in force at that time, each time it is called.

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!


	In POSIX my guess is (I'm no POSIX expert) that strftime("%Z")
is
	probably the correct way, that at least allows for some degree
of
	localisation, which localtime() certainly does not.

But that begs the question of where strftime gets the information.

	  | And I assume what is really wanted is the name at the time
of
	  | interest, so you can label output with the local time and
the
	  | abbreviation.

	If it is just for human consumption, and the human will already
have a pretty
	good idea what zone might be being referenced, then the zone
abbreviation
	is probably acceptable - you just cannot rely on its value being
useful for
	anything more than that 

Understood.


	(they're wildly ambiguous, and in the timezone
	package, for some zones, totally arbitrary and meaningless - in
many 
	(particularly smaller) countries the time is just the time, and
has
	no name by which it is distinguished from the time someplace
else.)

Gotcha.

  | (Forgive me for using Outlook;




--John





More information about the tz mailing list