This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING] 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>, 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: Sat, 12 Apr 2014 13:21:55 -0400
- Subject: Re: [PING] 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> <1397301884 dot 32837 dot YahooMailNeo at web192402 dot mail dot sg3 dot yahoo dot com> <534971E4 dot 6060001 at cs dot ucla dot edu>
On 04/12/2014 01:03 PM, Paul Eggert wrote:
> I'm afraid that subsequent discussion, both on this mailing list and
> on libc-help, has made it clear that the proposed API is not likely
> to reach consensus. The underlying application problem can already
> be addressed in a standard way, by setting and getting the TZ
> environment variable; it's not significantly harder to modify an
> entire application that way, as to modify it to add a nonstandard
> library call. And even if the need were greater, the proposed
> implementation does not work in general, because TZ binary files do
> not always end with strings that are appropriate TZ settings.
What needs to happen next IMO is that a design document (on the wiki) should
be written up for this work that includes and integrates the suggestions
by various reviewers including Paul's suggestion to look the APIs
that take and create timezone_t and how that should be integrated.
This is a core library, we don't accept hacks, and it takes a long time
to get new APIs accepted.
I don't entirely agree with Paul's points, but I also don't entirely disagree.
Where I disagree is that I think we could make a go at solving PJ's and
other developer problems by providing some way to query the existing in-use
local time as part of the whole and larger API addition to allow printing
locale time via timezone_t's.
Next steps that *someone* needs to do:
* Integrate feedback.
* Write up wiki page with new design.
* Discuss the various recommendations and show which one is best or
not best.
Discussing this further without summary or a document to reference is
going to get more and more difficult.
Cheers,
Carlos.