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

[P J P <pj dot pandit at yahoo dot co dot in>]

   Hello Russ,

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.

---
Regards
   -Prasad
http://feedmug.com