This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: RFC [PATCH] BZ#1077902: New API gettimezone
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Rich Felker <dalias at aerifal dot cx>, P J P <pj dot pandit at yahoo dot co dot in>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 04 Apr 2014 15:22:16 -0400
- Subject: Re: RFC [PATCH] BZ#1077902: New API gettimezone
- Authentication-results: sourceware.org; auth=none
- References: <1396499286 dot 85118 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <533CF5E8 dot 9010009 at cs dot ucla dot edu> <1396518081 dot 53447 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <533D73DF dot 1040009 at cs dot ucla dot edu> <1396546236 dot 69027 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <20140403194040 dot GG26358 at brightrain dot aerifal dot cx> <533DD86D dot 10908 at redhat dot com> <533DE5CA dot 5040905 at cs dot ucla dot edu> <533E16A5 dot 5030701 at redhat dot com> <533E1AB7 dot 5090804 at cs dot ucla dot edu> <533E471F dot 9040101 at redhat dot com> <533E562C dot 3040109 at cs dot ucla dot edu> <533E5910 dot 4000008 at redhat dot com> <533E61AC dot 4070905 at cs dot ucla dot edu>
On 04/04/2014 03:39 AM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> What's the problem and do we have a BZ open for this?
>
> I don't know of a BZ.
>
> The problem is that you're running a multithreaded server and you
> want to output a time stamp in the client's time zone. With glibc,
> that's a pain, since the TZ setting is process-wide, and if one of
> your threads sets TZ='Europe/Moscow' (say), then all your threads are
> affected.
>
> NetBSD addresses this by having functions like localtime_rz, which is
> like localtime_r except with an extra timezone_t argument. There are
> extra functions like tzalloc to create timezone_t objects. I don't
> know of any other system with these primitives other than Minix 3,
> which uses this part of NetBSD userland. See:
>
> http://netbsd.gw.com/cgi-bin/man-cgi?localtime_r++NetBSD-current
>
> It's been proposed to add these functions to the public-domain
> timezone code hosted by IANA, but nobody's gotten around to doing
> that yet.
Added to the master todo list:
https://sourceware.org/glibc/wiki/Development_Todo/Master#Date_and_Time_API
Along with a GSoC description for next year:
https://sourceware.org/glibc/wiki/GSoC#Thread-safe_and_timezone_aware_date_and_time_functions
Since this seems like something we could have a student implement.
I would think about extending tzalloc() to solve PJ's problem by
reserving a "localtime" keyword to mean "give me the current zone info."
resulting in an object we could use for further manipulation to pass
to a chroot'd process. This also means you can use the z variant APIs
for the local or non-local tz's all the same just by using the
reserved "localtime" keyword.
For example `char * tzget (const timezone_t tz);` where the string
is usable with TZ.
Note: tzgetname or tzgetzone (typo) are not usable for the purposes
of discovering the name of the timezone being currently used.
Just read the rather interesting historical read :-)
http://www.cl.cam.ac.uk/~mgk25/time/c/comment-eggert.html
Cheers,
Carlos.