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


Carlos O'Donell wrote:

Assumptions:

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

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

Another assumption: tz files don't change while applications are running, as the apps typically won't notice the change.

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

This should work but it's overkill.

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

This should also work, but it's also overkill. /etc/localtime is a zone info file, and you are already assuming that the containing server and the chrooted jail have matching zone info files. Therefore, /etc/localtime already matches, and there's no need to copy it.

If your assumption is violated and zone info files do not match, you and your containing-server admin need to decide collectively whether this mismatch is your problem or your server admin's problem, and then you and/or your server admin should fix the problem. This is true regardless of whether we change the glibc API in this area.

Because the server admin's goal should be to make your life easier, there should be no need for you to repair mismatched zone info files; they should just match. But if they don't match, and if you don't have the time or political oomph to get your server admin to fix them, then you need to fix your chrooted copy.

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

This should work if the API is fancy enough, but any such API (A) would need to be designed and implemented and tested and maintained, and (B) would probably expose some aspect of glibc internals. Down the road (B) would likely cause more trouble than it'd cure. Even (A) sounds like it's more trouble than the problem is worth.

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

(1) should work under the assumptions you gave, so in that sense it's correct; but it's not the only working solution and I would suggest something different.


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