This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: RFC [PATCH] BZ#1077902: New API gettimezone
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Rich Felker <dalias at aerifal dot cx>, P J P <pj dot pandit at yahoo dot co dot in>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Thu, 03 Apr 2014 22:19:17 -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> <533DE5CA dot 5040905 at cs dot ucla dot edu>
On 04/03/2014 06:50 PM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> What do we do then?
>
> We say, "sorry, the problem is out of scope". If you're trying to
> copy the contents of /etc/localtime to some random configuration, it
> might not even work there. These file formats change occasionally,
> for example.
>
> glibc doesn't need an API change. People who have this problem can
> save the contents of the TZ environment variable (or record that it's
> unset), and standardize on UTC in /etc/localtime. That's good
> enough.
>
> I'm redirecting this to libc-help because this thread is really more
> about helping someone use the system than about changing the libc
> API.
Your solution, particularly standardizing on UTC, imposes on the
developer to rewrite whatever software they are using for what
is an arbitrary decision of "Use UTC."
Can't we do better?
e.g.
char *ltz;
int ret;
ltz = gettimezone (NULL);
if (setenv ("TZ", ltz, 1) != 0)
/* Error. */
/* Run chroot'd process with TZ set in the environment. */
...
free (ltz);
Why is there no portable or reliable way to start a child process
with the same timezone as your own?
Even if we added a `settimezone (char *tz);` and passed data
to the child, that would be fine, and avoid the POSIX TZ style
issues.
Note that Windows 7 and 8 have functions like this that do
similar things, but that isn't a reason for adopting anything
like this, but an indication that Microsoft saw a need for
this (See [SG]etDynamicTimeZoneInformation).
Cheers,
Carlos.