[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