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: [PING^2] RFC [PATCH] BZ#1077902: New API gettimezone

On 04/30/2014 02:30 PM, Paul Eggert wrote:
> One way to work around the problem is to arrange for chrooted jail to
> have identical tz files as the main host.  That is necessary anyway,
> if you want gmtime->localtime mappings to match no matter how
> applications set TZ.  This sort of thing is standard practice for
> chrooted jails: one must set up configuration files, shared
> libraries, etc. to be the same in the jail as in the main host, and
> the tz files are just another part of this.

It's also necessary to have the same locales in both places if
you are expecting localization to work correctly across the

However, even if you had identical files there is presently no
programmatic API to determine your own TZ, and that's part of
the flaw. For localization it's easy you use "setlocale(LC_ALL, NULL);".

The workaround that is suggested is to always set TZ on the
server. Unfortunately that requires administrative privileges
or knowing exactly which file was symlinked, hardlinked, or
copied into /etc/localtime. What if you're on a locked down
VM? Running in an OpenShift gear with no access to /etc/localtime
and no chance of getting OpenShift to modify the server for

It would be easier to just have an API that tells you your
current tz so you can use it to set TZ.

Do we agree that there is a flaw in the API here?


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