[ccan] thread-safe timezone conversion code

David Lang david at lang.hm
Fri Sep 13 12:37:48 EST 2013


It really seems to me like the right answer _should_ be that glibc should split 
their current routines in half, the first half looks up the local timezone as it 
does today, and then calls the second half where the local timezone is passed as 
an explicit parameter, and both routines get exposed to userspace. If the code 
is really well organized, this is probably not more than a dozen lines insert 
the call to the second function, the end of the first function, and the header 
of the second function in the right place)

But in the research I've done over the last couple of days, it looks like this 
has been suggested for several years with absolutly zero progress. :-(

So I'm out looking for other options.

David Lang


  On Fri, 13 Sep 2013, Sam Watkins wrote:

> Date: Fri, 13 Sep 2013 11:36:38 +1000
> From: Sam Watkins <sam at nipl.net>
> To: Rusty Russell <rusty at rustcorp.com.au>
> Cc: David Lang <david at lang.hm>, ccan at lists.ozlabs.org
> Subject: Re: [ccan] thread-safe timezone conversion code
> 
> David Lang:
>> Subject: Re: [ccan] thread-safe timezone conversion code
>
> You could I suppose hack something together based on one of e.g. glibc,
> bsd libc, uClibc, musl, or plan 9 libc timezone code, without too much
> difficulty.
>
> Sam
>
>


More information about the ccan mailing list