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>