This is the mail archive of the
mailing list for the glibc project.
Re: RFC [PATCH] BZ#1077902: New API gettimezone
- From: P J P <pj dot pandit at yahoo dot co dot in>
- To: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Fri, 4 Apr 2014 13:32:48 +0800 (SGT)
- 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>
- Reply-to: P J P <pj dot pandit at yahoo dot co dot in>
> On Friday, 4 April 2014 4:21 AM, Paul Eggert wrote:
> glibc doesn't need an API change.
It is not an API change. But a fresh new API.
> 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.
TZ is not set by default on most systems for '/etc/localtime' is almost always accessible.
For cases when it is not accessible, we need to know appropriate value for the TZ variable. Which is precisely what this new API 'gettimezone()' provides.
Defaulting to UTC when TZ is not set is an easy solution. Many applications did that in the past. But it does not work for users. First, it's a usability disaster and second they have to maintain separate scripts to do time conversions from UTC to their local time when reading timestamps. Imagine reading a log file wherein timestamps are in UTC. First question any user would ask is why is not local time?
> about helping someone use the system than about changing the libc API.
It is about a new API that is genuinely useful. Not about changing any existing API.