This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING^2] 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, 3 May 2014 02:50:17 +0800 (SGT)
- Subject: Re: [PING^2] RFC [PATCH] BZ#1077902: New API gettimezone
- Authentication-results: sourceware.org; auth=none
- References: <1396499286 dot 85118 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <1397301884 dot 32837 dot YahooMailNeo at web192402 dot mail dot sg3 dot yahoo dot com> <534971E4 dot 6060001 at cs dot ucla dot edu> <53497633 dot 6060804 at redhat dot com> <1397324033 dot 69177 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <5349A4B0 dot 2070206 at redhat dot com> <1397375798 dot 36419 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <1397414803 dot 70882 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <534B8A9F dot 8030806 at redhat dot com> <1397469748 dot 42212 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <1398146221 dot 72442 dot YahooMailNeo at web192403 dot mail dot sg3 dot yahoo dot com> <1398755742 dot 94004 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <535F74EE dot 8010002 at redhat dot com> <1398775268 dot 92264 dot YahooMailNeo at web192405 dot mail dot sg3 dot yahoo dot com> <535FC11B dot 3000906 at cs dot ucla dot edu> <1398801168 dot 81041 dot YahooMailNeo at web192406 dot mail dot sg3 dot yahoo dot com> <5360378D dot 1060306 at cs dot ucla dot edu> <1398872997 dot 84757 dot YahooMailNeo at web192402 dot mail dot sg3 dot yahoo dot com> <878uqmo3rq dot fsf at windlord dot stanford dot edu> <1398926170 dot 36710 dot YahooMailNeo at web192401 dot mail dot sg3 dot yahoo dot com> <877g652zrc dot fsf at windlord dot stanford dot edu>
- Reply-to: P J P <pj dot pandit at yahoo dot co dot in>
Hello Russ,
Thank you for the explanation.
> On Thursday, 1 May 2014 10:38 PM, Russ Allbery <eagle@eyrie.org> wrote:
> The TZ string is only applicable to times *after* the last transition time
> stored in the file. In other words, if the file has any specific data for
> a given time period, that data overrides the TZ string. The TZ string is
> supposed to be used only as a fallback for times that are beyond the date
> range represented in the database file.
Ah, I see. Well, then the new API could be used to return the most suitable value amongst all available.
> Any other approach will produce incorrect local times. In some areas,
> such as the US, the inaccuracies will only be for historical times. In
> others, they may be inaccurate even for current or near-future times.
>
> Unless I'm mistaken and am missing some representational power in the
> format, I believe the other POSIX time zone settings cannot accurately
> represent the complexity of real-world time zones.
>
> Now, obviously, if you can make simplifying assumptions for a specific
> application, you may be able to use other TZ settings and be correct
> within the problem domain of your application. For example, if you only
> care about forward-looking timestamps in the America/Los_Angeles zone, you
> can use a fairly simple TZ rule and be as accurate as the full database
> would be (namely, accurate until the US Congress changes daylight saving
> time again). There are probably many applications that can make such
> simplifying assumptions. But I'm dubious that glibc can do so.
Hmmn, I understand your concern.
The thing is, we are seeking to rely on the fall-back TZ string option because there is none other more suitable for the case in point, ie. chroot(2) jail. Wherein, the system's time zone data is not readily accessible. It that, glibc is not making simplifying assumptions, but merely facilitating it, if the users want to do so.
---
Regards
-Prasad
http://feedmug.com