Re: localtime() vs localtime_r()

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.