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

[Russ Allbery <eagle at eyrie dot org>]

P J P <pj.pandit@yahoo.co.in> writes:

> Â Hi,

>> On Wednesday, 30 April 2014 5:07 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

>> 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.

> Â Sorry, it's confusing. What is the problem here? It sounds more of
> incorrect or buggy time zone file. Which is a different issue. We can
> not deem TZ variable unreliable for it.

Let me take a different approach to this, since it feels like you and Paul
are talking past each other.  Maybe I can explain it in a different way
and that will help.

Most people are probably used to fairly predictable time zone rules, where
the time either never changes for a given area or changes twice a year for
something called either "daylight saving time" or "summer time," always
changing on the same day according to some predictable rule, such as 2am
on the second Sunday in March.

However, while this sort of predictability of time zones is a common
property, it is *not* a universal property.  If it were, the work of the
tz mailing list, and Paul as primary maintainer, would be considerably
simpler.

There are some regions where the transition date of daylight saving time
is determined by statute every year, independently, with no forward
guidance given.  In other words, the legislature passes a law, hopefully
reasonably in advance of the start of daylight saving time (but often
not), saying when it will start and end that year, with only casual
attention paid to when it started and ended in previous years.  Or there's
a yearly battle over whether daylight saving time should exist at all, and
sometimes it happens and sometimes it doesn't.  Or there are two
neighboring time zones with which it would be convenient to agree, and the
local time flips back and forth between them at political whim or based on
larger geopolitical concerns at the time.

Cases like this are why the tz database receives regular updates.

I believe that the rule that you're looking to populate in the TZ variable
is the "forward-looking" rule for the zone.  This is the rule that's used
in the absence of any better information for the specific time period in
question.  Usually, it's a blind forward projection of whatever rule was
in place for the year when the database was updated.  Sometimes it's not
even that, such as in the example Paul gave.  Sometimes the best available
information is that the current year is an aberration and the best forward
projection is some previous year, in which case using that rule will get
*current* time wrong, or in this case, the time for next year.

The database says that the rule should not be used for times in those
ranges, so the database is not buggy.  It's just not suited to how you're
trying to use it.

At best, these sorts of forward projections might be correct for
predictable and stable zones like the largest United States time zones or
most European zones, barring fairly disruptive changes in laws.  It is,
however, known to be wrong for some of the zones where the transition
times are determined yearly by statute.  And even when it's not known to
be wrong, it's a guess, and is still likely to be wrong on any given year
until the legislature actually takes up the issue.

This is setting aside the fact that any single rule string cannot easily
represent all the various changes and complexity of historical time, so at
best you would get accurate localtime results for the current time and
possibly times into the future, but those times will often be wrong for
dates in the past because you've discarded most of the rule file.

-- 
Russ Allbery (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>