This is the mail archive of the
mailing list for the glibc project.
Re: RFC [PATCH] BZ#1077902: New API gettimezone
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: P J P <pj dot pandit at yahoo dot co dot in>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 03 Apr 2014 22:33:04 -0400
- Subject: Re: RFC [PATCH] BZ#1077902: New API gettimezone
- Authentication-results: sourceware.org; auth=none
- References: <1396499286 dot 85118 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <533CF5E8 dot 9010009 at cs dot ucla dot edu> <1396518081 dot 53447 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <533D73DF dot 1040009 at cs dot ucla dot edu> <1396546236 dot 69027 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <20140403194040 dot GG26358 at brightrain dot aerifal dot cx> <533DD86D dot 10908 at redhat dot com> <20140403222601 dot GK26358 at brightrain dot aerifal dot cx>
On 04/03/2014 06:26 PM, Rich Felker wrote:
>> 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.
> This is a reasonable request, but it doesn't help unless you can copy
> the file into the chroot.
We are now in the realm of implementation-defined behaviour so we have
On Linux you could conceivable encode the timezone compressed into the
TZ var, the largest timezone we have is less than 10kb. That would work
and allow you to pass the entire zone info to the child process without
any coordination or requirement that installed tzdata be compatible.
If you choose not to go this route you can simple document that the
tzdata in the created process must be compatible. This is much more
sensible since the zone info has been around for a long time and will
therefore be generally correct until updated.
>> 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.
> If it only knows a pathname in the outside-chroot filesystem, how is
> it supposed to translate that to an equivalent TZ inside the chroot?
> Search the zoneinfo tree for a binary-identical file?
Use the same path in the chroot and expect tzdata to be as new or newer?
It is much easier for the higher level framework to look at the package
database, determine if all the required packages are in place e.g. a
tzdata that is newer or the same as your tzdata (expecing backwards
You can enforce package version requirements much easier than we can
request root and read-write of the root filesystem to copy /etc/localtime.
You can then abort launching the chroot'd process if the tzdata isn't
new enough that the chroot can run with the right time.
>> What do we do then? What API or service do we offer?
> TZ service would work but may be overkill...
If we made a tz service operate like ntp it would be quite nice.
- The request is for an API that allows you to query your own
timezone in sufficient detail to start another process with the
same timezone or a different timezone.
- The value returned by gettimezone could be:
- Relative path to the zoneinfo file (requires matching tzdata).
Absolute path to the zoneinfo file (").
* My preferred solution.
- Encoded copy of the zoneinfo file (requires libc that can read this).
- Opaque token (requires coordination with tzdata).
- Like a uuid with version for each zone.
At present the best known solutions are:
- Standardize on UTC.
- Copy /etc/localtime into the chroot.
- Requires the ability to write to the chroot
- Read /etc/localtime, if it's version-2-format then continue
reading the last line of the file which represents the closes
possible POSIX TZ and use that even if that might not be as
accurate as the zoneinfo. You can't use this if the line is
- Use existing APIs to gather information about the current
timezone, construct a POSIX-TZ-enviroment-variable-style
string and use that for the chroots TZ value. Again this is
inaccurate because it doesn't have enough information.
I need to think about this some more.