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: Paul Eggert <eggert at cs dot ucla dot edu>
- To: P J P <pj dot pandit at yahoo dot co dot in>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 29 Apr 2014 16:36:45 -0700
- 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>
P J P wrote:
Do we know why is it completely wrong, when it is wrong?
The TZ string contains a prediction of DST behavior after the rest of
the zoneinfo file's history expires; in general it's incorrect to use
this string at other times. For example, the TZ string at the end of
America/Sao_Paolo is "BRT3BRST,M10.3.0/0,M2.3.0/0", which corresponds to
our best guess for what happens after the year 2038. Unfortunately,
this guess is known to be wrong next year, as Sao Paolo is scheduled to
switch back to standard time on 2015-02-22, not on 2015-02-15. So
shipping TZ="BRT3BRST,M10.3.0/0,M2.3.0/0" to a remote site will
mishandle many time stamps in Brazil.
Because if without the TZ string or with TZ=UTC0, <time.h> APIs can provide accurate UTC times, then all TZ definition helping us with is the offsets and time frame within an year.
Sorry, I don't understand this comment.
I said UTC is reasonable when the TZ string is absent from the time zone file. Ie. it is the *last* resort, when no other option is *available/possible*.
I'm afraid no other option is available or possible under reasonable
constraints, if the goal is to have gmtime->localtime conversion on the
remote host exactly match gmtime->localtime conversion with TZ unset on
the local host even if the two hosts don't have identical tz setups.
One way to work around the problem is to arrange for your hosts to have
identical tz setups. That is something you need to do anyway if you
want gmtime->localtime mappings to match on all hosts.