This is the mail archive of the
libc-alpha@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: Rich Felker <dalias at aerifal dot cx>, P J P <pj dot pandit at yahoo dot co dot in>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 03 Apr 2014 17:53:49 -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>
On 04/03/2014 03:40 PM, Rich Felker wrote:
> On Fri, Apr 04, 2014 at 01:30:36AM +0800, P J P wrote:
>>> On Thursday, 3 April 2014 8:15 PM, Paul Eggert wrote:
>>
>>> Yes, absolutely. Saying "I want to print the contents of /etc/localtime"
>>> is not a compelling argument.
>>
>> Heh...who said that?
>>
>>> Why do you want to print its contents?
>>
>> Did you see the bug that is listed in the subject line? If not, please see:
>> -> https://bugzilla.redhat.com/show_bug.cgi?id=1077902.
>
> Classic XY problem. Generating a POSIX TZ string does not solve your
> chroot problem, and there's a much simpler approach that does solve
> it. I replied on the bug tracker.
The fundamental problem is that it would be nice to have a way
to query the current timezone and launch another process using the
same timezone despite the fact that the the other process might
run in a different configuration (say a chroot, or container defaulting
to EST5EDT).
Why can't the POSIX TZ solve the problem using the ":character"
implementation-defined meaning? We already use this in glibc to
support ":/path/to/tz/file"
The new gettimezone API could just return ":/path/to/tz/file"
which is the expected locale that should be used for current timezone.
The problem could be that your chroot is read-only or part of some
container whose core image is read-only. I don't know that we can
expect the caller to be able to modify the chroot, but it can
certainly adjust the environment to attempt to set the right timezone.
What do we do then? What API or service do we offer?
Cheers,
Carlos.