This is the mail archive of the
mailing list for the glibc project.
Re: [PING^2] RFC [PATCH] BZ#1077902: New API gettimezone
- From: P J P <pj dot pandit at yahoo dot co dot in>
- To: Russ Allbery <eagle at eyrie dot org>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 1 May 2014 14:36:10 +0800 (SGT)
- 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>
- Reply-to: P J P <pj dot pandit at yahoo dot co dot in>
Thanks so much for the explanation.
> On Thursday, 1 May 2014 3:53 AM, Russ Allbery wrote:
> 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.
Agreed and understood. For some region the DST settings change each year.
> 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??
> 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.
> 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.
(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??
> 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.
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 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.