From owner-freebsd-current@FreeBSD.ORG  Tue Apr  1 11:24:55 2008
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from alona.my.domain (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP id 5979E106564A;
	Tue,  1 Apr 2008 11:24:53 +0000 (UTC)
	(envelope-from davidxu@freebsd.org)
Message-ID: <47F21BA7.5030309@freebsd.org>
Date: Tue, 01 Apr 2008 19:25:27 +0800
From: David Xu <davidxu@freebsd.org>
User-Agent: Thunderbird 2.0.0.9 (X11/20080323)
MIME-Version: 1.0
To: Peter Jeremy <peterjeremy@optushome.com.au>
References: <47F05C44.9020603@freebsd.org>
	<20080401105909.GD24181@server.vk2pj.dyndns.org>
In-Reply-To: <20080401105909.GD24181@server.vk2pj.dyndns.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: Re: localtime() vs localtime_r()
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2008 11:24:56 -0000

Peter Jeremy wrote:
> On Mon, Mar 31, 2008 at 11:36:36AM +0800, David Xu wrote:
>   
>> According POSIX specification, it seems localtime_r() is not only
>> a reentrant version of localtime(), but also a performance-wise version.
>>     
>
> IMO, localtime_r() is _not_ reentrant because it implicitly uses TZ
> from the environment, rather than having TZ (ither as TZ or struct
> state) passed as an argument.  I have an application that does
> conversions between timezones and this lack is a PITA.
>
>   
it means it does not access TZ at all. As long as the specification says 
it does not set
timezone,  an application relies on localtime_r() to set timezone is not 
portable.

>> Our implementation does set tzname, tomezone and daylight, it is a bit
>> slower than glibc because ours has to call getenv() everytime.
>>     
>
> Given that POSIX stuffed the definition of localtime_r(), it's not
> clear how to avoid this.  I guess you could change the tzset_basic()
> call in localtime_r() to something like:
> 	static initialised = 0;
> 	if (!initialised) {
> 		tzset_basic();
> 		initialised = 1;
> 	}
> which means it won't see changes to TZ.
>
>   

I think just calling tzsetwall_basic() is enough.