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:
> On Thursday, 1 May 2014 3:53 AM, Russ Allbery wrote:

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

> Â Ie. the TZ string at the end of the time zone file is a prediction of
> how DST would work next year, instead of this(current) year? Did I get
> it right??

No, not quite.  Here's the description from the tzfile man page:

    After the second header and data comes a newline-enclosed, POSIX-TZ-
    environment-variable-style string for use in handling instants after
    the last transition time stored in the file (with nothing between the
    newlines if there is no POSIX representation for such instants).

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.

So in some cases the TZ string may represent time for next year, if there
is, as yet, no data for next year.  In some cases, it may only be accurate
for time after 2016, or 2020, or 2040, if we have data for all times up to
that point.

In some regions, for example, the rule for daylight saving time is based
on some complex calculation that cannot be represented in a POSIX TZ
string, in which case the database generally contains yearly rules going
quite some distance forward and then either a known-incorrect but not
*too* incorrect TZ string or none at all.

Regardless, using that TZ string for current time, or for any time that
has an actual database rule, is incorrect under the data model of the
file, and in some cases will result in real time errors.

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

> Sorry, I did not get this part.

I believe you're proposing extracting a fallback rule from a file whose
format is explicitly defined as saying the fallback should only be used
when there is no more specific rule, and using it unconditionally
regardless of whether there's a more specific rule.  Problems caused by
that approach do not represent a bug in the database.

> (to confirm) Say 'Sao Paulo' enters DST on 15th March and exits DST on
> 15th October. In case, on 20th February Sao Paulo's court decides to
> enter DST on 15th Apr and exit on 15 Nov, then the systems would not
> reflect that because the tzdata files are not updated to have the new
> time window. And as result, localtime(3) would show incorrect times for
> 30 days? Did I get it right??

That's the problem with time zone data in general, yes.  But by using the
fallback TZ rule blindly, one would make the problem worse and get times
wrong even if we *do* know what the transitions are and those transitions
are properly documented in the rest of the database file.

> So because the tzdata files include the historical time zone settings,
> one can compute accurate times of the past too. That won't be possible
> if TZ variable is set to the current time zone settings, right?

I am not deeply familiar with the syntax of the POSIX TZ variable, but I
don't believe it can represent multiple rules in different date ranges.

> I think that is the limitation of the TZ variable we'll have to live
> with. Because its syntax does not provide room to hold 'complete'
> contents of a time zone file. If it did, I'm sure we would have defined
> it accordingly.

I, and I suspect many others who care about accurate local time, would
tell you that there are only two reliable ways to use the TZ variable: set
it to UTC and give up on the idea that you know what local time is, or set
it to the identifier of a tz database file that has the accurate time
transitions.

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.

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