This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC [PATCH] BZ#1077902: New API gettimezone

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:
>> ->
> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]