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 08:49 AM, P J P wrote:
It sounds more of incorrect or buggy time zone file.

No, that time zone file is not buggy. It's generated by the standard tzdata distribution, it uses the documented file layout, and many other time zone files are like it. For details, please see the tzfile man page.

TZ variable provides offsets which are added to the UTC times to get the local time, right?

That's basically right. (TZ also can provide leap-second info, which maps TAI to UTC, but let's ignore that for now.)

Goal is to make local system time zone definition available to processes running inside of a chroot(2) jail; On the same host.

Sorry, that point was never made clear to me. In that case, please let me rephrase my remark, as follows:

I'm afraid no other option is available or possible under reasonable constraints, if the goal is to have gmtime->localtime conversion in the chrooted jail exactly match gmtime->localtime conversion with TZ unset outside the jail regardless of whether the jail and the main host have identical tz files.

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.

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