[PING^2] RFC [PATCH] BZ#1077902: New API gettimezone

[Paul Eggert]

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.