This is the mail archive of the
mailing list for the glibc project.
Re: [PING^3] RFC [PATCH] BZ#1077902: New API gettimezone
- From: P J P <pj dot pandit at yahoo dot co dot in>
- To: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Sat, 31 May 2014 04:02:15 +0800 (SGT)
- 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> <53882317 dot 6050002 at cs dot ucla dot edu> <1401443081 dot 1000 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <5388984F dot 3010700 at cs dot ucla dot edu>
- Reply-to: P J P <pj dot pandit at yahoo dot co dot in>
> 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?