Date: Tue, 01 Apr 2008 19:25:27 +0800 From: David Xu <davidxu@freebsd.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: localtime() vs localtime_r() Message-ID: <47F21BA7.5030309@freebsd.org> In-Reply-To: <20080401105909.GD24181@server.vk2pj.dyndns.org> References: <47F05C44.9020603@freebsd.org> <20080401105909.GD24181@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F21BA7.5030309>