This is the mail archive of the
mailing list for the glibc project.
Re: RFC [PATCH] BZ#1077902: New API gettimezone
- From: keld at keldix dot com
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, P J P <pj dot pandit at yahoo dot co dot in>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Fri, 4 Apr 2014 15:11:24 +0200
- 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>
On Thu, Apr 03, 2014 at 05:53:49PM -0400, Carlos O'Donell wrote:
> 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?
I think we should take into account the timezone keyword of the LC_TIME category in ISO TR 30112.
I think we should aim at least at an API, and I am happy to include a description
of the API in the revision of 30112.