Does any one remember the logic behind sp->goback and sp->goahead in localtime.c?
AFAICT, the logic associated with sp->goback and sp->goahead in tzload() and in localsub() in localtime.c could only ever be used if there were at least 800 time change entries, enough for two per year for a 400 year cycle. And, empirically, there are no time zone definitions in the current (2007k) data set that get anywhere close to this. However, this code can't have been put in there for no reason whatsoever, so I'd like to understand what was the intention - if anybody can remember. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
Jonathan Leffler wrote:
AFAICT, the logic associated with sp->goback and sp->goahead in tzload() and in localsub() in localtime.c could only ever be used if there were at least 800 time change entries, enough for two per year for a 400 year cycle. And, empirically, there are no time zone definitions in the current (2007k) data set that get anywhere close to this.
However, this code can't have been put in there for no reason whatsoever, so I'd like to understand what was the intention - if anybody can remember.
I'm not positive, but I *think* that it was an effort to support solar time in the Arab countries; solar time was approximated by making several hundred time zone changes *per year*. The legacy 'solar87,' 'solar88' and 'solar89' files in tzdata show what was being tried. -- 7e de ke9tv/2, Kevin
On Jan 12, 2008 6:52 PM, Kevin Kenny <kkenny2@nycap.rr.com> wrote:
Jonathan Leffler wrote:
AFAICT, the logic associated with sp->goback and sp->goahead in tzload() and in localsub() in localtime.c could only ever be used if there were at least 800 time change entries, enough for two per year for a 400 year cycle. And, empirically, there are no time zone definitions in the current (2007k) data set that get anywhere close to this.
However, this code can't have been put in there for no reason whatsoever, so I'd like to understand what was the intention - if anybody can remember.
I'm not positive, but I *think* that it was an effort to support solar time in the Arab countries; solar time was approximated by making several hundred time zone changes *per year*. The legacy 'solar87,' 'solar88' and 'solar89' files in tzdata show what was being tried.
Thanks, Kenny. I'm not sure whether that was it or not. I think not - but that was interesting information (I'd not really looked at the solar8x files). However, it appears my testing wasn't as thorough as I thought. Under at least some circumstances, a zone such as US/Mountain can generate lots of entries as it goes forward, using the TZ environment variable embedded in the zone info file. Life is simpler for places without summer/winter time - which tend to be close to the equator. Since I'd got debug code in place that suddenly seemed to start printing, I was a bit bemused about what I did wrong before - how did I miss it. [...time passes...] It was because I switched between a 32-bit and a 64-bit build of the code. With the 64-bit build and a 64-bit time_t, you can go a lot further forwards than you can with 32-bit code and a 32-bit time_t, where you're stuck from early 2038 onwards. I was right that the extra entries do not appear in the zone info files, though. So, I appear to have given a false alarm, for which I apologize. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
The goahead and goback logic did indeed get added when work was being done on supporting 64-bit time_t values. On 64-bit time_t systems, even when time zone data files don't contain 800 explicit transitions, the files may contain a POSIX environment variable value from which transitions can be determined; the zone loading software will fill in transition tables using the environment variable value, and the goahead and goback logic will kick in. The logic handles current real-world cases; it could be improved. Recall the effort a few years ago to extend daylight saving time on the Pacific coast of the United States during election years (as a way of reducing the impact of reported east coast voting on west coast voting). If the extension had been adopted, there'd still be a 400-year cycle of transitions, but there might be more than 800 transitions in the cycle (in particular, every four years the Pacific coast might move through "Pacific Daylight Time" and then "Pacific Presidential Election Time" and then "Pacific Standard Time." (Were this true, there'd be no POSIX-style variable that could describe the transitions.) So goahead should really be set by searching the table to see if there's a transition that's exactly 400 years before the last transition in the table with a type that's the same as that of the last transition in the table (and similarly for goback). --ado
participants (3)
-
Jonathan Leffler -
Kevin Kenny -
Olson, Arthur David (NIH/NCI) [E]