This is the mail archive of the
mailing list for the glibc project.
Re: [PING^2] RFC [PATCH] BZ#1077902: New API gettimezone
- From: Russ Allbery <eagle at eyrie dot org>
- To: P J P <pj dot pandit at yahoo dot co dot in>
- Cc: "libc-alpha\ at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 01 May 2014 10:08:07 -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> <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>
P J P <firstname.lastname@example.org> 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
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
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 (email@example.com) <http://www.eyrie.org/~eagle/>