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 Friday, 30 May 2014 8:10 PM, Paul Eggert wrote:
> As already discussed, applications already have a way to 
> solve the problem, one that is widely used and portable: they can set TZ 
> to "UTC0" (or to whatever other value they like).  We can therefore 
> leave things alone; there's no need for an extension.

  1. Sure! We have no contention with user setting the TZ variable.
  2. We are saying that we need to facilitate the user to _know_
     the possible values he/she can use to initialise the TZ variable.

  3. Because if they decide to use non "UTC0" value, they would need
     to account for the Daylight Savings Time(DST) offset.

  4. That implies that they should be able to define the TZ variable
     in the following syntax

     -> std offset dst [offset],start[/time],end[/time]

  5. Currently there is no standard way for users to _know_ such value.
     And the given new API addresses this issue.
> Again, we are going around in circles.  The 'best fit' is not the TZ 

> string at the end of the tzdata file.  It is not any other line from the 
> tzdata file.  It is not in the tzdata file anywhere.  You are asking for 
> something that does not exist.

  Again you are overlooking the _fact_ that if you ask users to define TZ variable, they are in most certainty, going to define it as the closet approximation _available_ to them. Most likely the last line from the tzdata file.

If the theoretical accuracy and precision that you seek does not exist, why not provide what is available and what we can?


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