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

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

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

  That is precisely what the new API for which the patch was submitted early in this thread aims to do.

  1. Many of those applications depend on the value provided by TZ variable.
     Irrespective of whether it is accurate or an approximation.
  2. TZ variable can not accommodate entirety of a tzdata file.
     Because it's standard documented format allows only for a limited definition.
  3. Today if a user has to set TZ variable it is always going to be such limited definition.
     And there are other users who prefer TZ=UTC+0.

Considering these facts, we know that users already use & rely on the limited definition in 'TZ' variable. We are merely trying to facilitate them to easily find the suitable or 'best fit' TZ value.

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.

> a halfhearted approximation that could well cause more problems than it'll fix.

  And what are these more problems?


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