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


On 05/01/2014 01:53 PM, Paul Eggert wrote:
> On 05/01/2014 12:05 AM, Carlos O'Donell wrote:
>> getenv ("TZ"); right now on an OpenShift gear returns "", and if I
>> pass my cartridge to someone running in Mumbai, and they use it the
>> chroot'd process prints the wrong time.
> 
> If getenv ("TZ") returns the empty string both here and in Mumbai,
> glibc localtime will use UTC in both places, so you should be OK.

Let me refine the questions because we're talking past each other
at this point.

Goal:

- Set the local time in the chroot to match the server local time.

Assumptions:

- Server and chroot have updated and matching zone info files.

- You don't control the server e.g. OpenShift Gears or Docker.

Solutions:

(1) Have the administrator of the server set the TZ env var to match
  /etc/localtime.

  - Not easy. Extra step for admin.

  - The TZ env var propagates to chroot'd application and time
    is fine.

(2) Copy the /etc/localtime file from the server to the chroot.

  - Requires a RW chroot which is inefficient if you are running
    say on docker in which you desire to keep your base images
    identical. Changes to the images are *real* $$$ costs in say
    EBS storage from AWS.

(3) Provide an API for users to learn what their zone is.

  - User queries zone, sets TZ, and runs chroot'd application.

  - Adds API complexity.

Is you opinion that (1) is the correct solution?

Cheers,
Carlos.


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