RFC [PATCH] BZ#1077902: New API gettimezone

[keld@keldix.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.


Best regards
keld