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. >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. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:29 UTC