<br><div class="gmail_quote">On Jan 12, 2008 6:52 PM, Kevin Kenny <<a href="mailto:kkenny2@nycap.rr.com">kkenny2@nycap.rr.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Jonathan Leffler wrote:<br>> AFAICT, the logic associated with sp->goback and sp->goahead in tzload()<br>> and in localsub() in localtime.c could only ever be used if there were<br>> at least 800 time change entries, enough for two per year for a 400 year
<br>> cycle. And, empirically, there are no time zone definitions in the<br>> current (2007k) data set that get anywhere close to this.<br>><br>> However, this code can't have been put in there for no reason
<br>> whatsoever, so I'd like to understand what was the intention - if<br>> anybody can remember.<br><br></div>I'm not positive, but I *think* that it was an effort to support solar<br>time in the Arab countries; solar time was approximated by making
<br>several hundred time zone changes *per year*. The legacy 'solar87,'<br>'solar88' and 'solar89' files in tzdata show what was being tried.<font color="#888888"><br></font></blockquote></div><br>
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).<br><br>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.
<br><br>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.<br><br>[...time passes...]<br><br>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.
<br><br>I was right that the extra entries do not appear in the zone info files, though.<br><br>So, I appear to have given a false alarm, for which I apologize.<br><br>-- <br>Jonathan Leffler <<a href="mailto:jonathan.leffler@gmail.com">
jonathan.leffler@gmail.com</a>> #include <disclaimer.h><br>Guardian of DBD::Informix - v2007.0914 - <a href="http://dbi.perl.org">http://dbi.perl.org</a><br>"Blessed are we who can laugh at ourselves, for we shall never cease to be amused."