This is the mail archive of the libc-alpha@sourceware.org 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 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.

This is a reasonable request, but it doesn't help unless you can copy
the file into the chroot.

> 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.

If it only knows a pathname in the outside-chroot filesystem, how is
it supposed to translate that to an equivalent TZ inside the chroot?
Search the zoneinfo tree for a binary-identical file?

> What do we do then? What API or service do we offer?

TZ service would work but may be overkill...

Rich


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