This is the mail archive of the
mailing list for the glibc project.
Re: [PING^3] RFC [PATCH] BZ#1077902: New API gettimezone
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: 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, 29 May 2014 23:20:07 -0700
- Subject: Re: [PING^3] RFC [PATCH] BZ#1077902: New API gettimezone
- Authentication-results: sourceware.org; auth=none
- References: <5361F22E dot 3070206 at redhat dot com> <53628A02 dot 9080702 at cs dot ucla dot edu> <53629388 dot 1060301 at redhat dot com> <53630B0C dot 1050305 at cs dot ucla dot edu> <53633A37 dot 7060405 at redhat dot com> <5363E223 dot 7060303 at cs dot ucla dot edu> <1399061963 dot 56150 dot YahooMailNeo at web192404 dot mail dot sg3 dot yahoo dot com> <1401211363 dot 50264 dot YahooMailNeo at web192402 dot mail dot sg3 dot yahoo dot com> <20140527180827 dot GA25042 at domone dot podge> <538533EB dot 3000501 at cs dot ucla dot edu> <20140528085726 dot GA975 at domone dot podge> <5385F400 dot 2070201 at cs dot ucla dot edu> <1401357566 dot 99673 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <53873C3C dot 8050502 at cs dot ucla dot edu> <1401429290 dot 18994 dot YahooMailNeo at web192406 dot mail dot sg3 dot yahoo dot com>
P J P wrote:
On Thursday, 29 May 2014 7:25 PM, Paul Eggert wrote:
Yes, application dependent. Scheduling applications, for example, are
more interested in times in the near future, whereas date-of-birth
applications are more interested in times in the medium-distant past.
They have different needs for the "best fit".
I doubt if such applications have any need for a 'best fit' definition, because they do have access to the system's tzdata files.
No, these applications typically don't access the system's tzdata files
directly. They use the glibc API (or its POSIX subset) to get timezone
If the problem cannot easily be solved in glibc then let's be honest and
leave things alone, and let application developers continue to solve the
problem in the same simple and portable way that they've solved it for
That is precisely what the new API for which the patch was submitted early in this thread aims to do.
No, the patch proposes a change to the API, which would require programs
to change if they want to use the new facility. This is not leaving
It'll greatly help to discuss whether 'best fit' is the TZ string at the end of the tzdata file, when it is present, or any other line from the tzdata file.
It's not the 'best fit'. There is no such thing as a global 'best fit';
as I explained to you, and as Russ Allbery explained in
At this point I feel like we are going around in circles, as you are not
responding to the issues raised and are merely repeating your proposal.