This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING^3] RFC [PATCH] BZ#1077902: New API gettimezone

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 information.

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 things alone.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]