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 03:02:40 -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>
On 04/04/2014 02:50 AM, Paul Eggert wrote:
>> it is a flaw in the API not to provide
>> a way for the application to both query and set the timezone.
>
> But there is a way: get and set the TZ environment variable. True,
> this doesn't let you get at the contents of /etc/localtime when TZ is
> unset; but the simple solution is to not rely on /etc/localtime, and
> to always set TZ.
It's a fragile solution, but a workable one I could recommend.
>> While I agree that using UTC simplifies things, and that it may
>> be the case that wide-spread use of UTC will fix these problems,
>
> Not "will fix". *Has* fixed. It's what people have been doing for
> *decades*, and it *works*.
Point taken.
>> I don't see using UTC as an acceptable solution for all users
>
> People who want to run non-UTC servers (which is a bad idea) can set
> TZ. Problem solved.
OK.
>> Is something like tzget() really a bad idea?
>
> Something like that *might* be implemented. But doing it right would
> be a lot of work for a small benefit. There are far more-pressing
> problems in the time zone API, such as, why isn't there a thread-safe
> way to set and get the time zone? If you want to work on improving
> this area of glibc, please work on *that*. That's a *real* need, and
> there's existing practice (NetBSD).
I'm all ears. What's the problem and do we have a BZ open for this?
My first guess is that TZ/tzset() are two operations that can't be
performed atomically, and that setenv() is only MT-safe as long as
nobody modifies the environment.
I'm happy to copy BSD* interfaces :-)
Cheers,
Carlos.