<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). 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.

<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."